TwinBee

Laura Renner
CST 499 Directed Group Capstone
Gregory Brown and Dalia Faria
31 May 2020
 
Executive Summary

Our client Laura Renner, the Founder and Managing Director of Freedom Makers, is

looking to rectify issues that occur when billing clients’ for prepaid payment plans based on their

independent contractor’s reported timesheets. The issues interfere with their ability to accurately

determine their clients’ rolling prepaid hours between pay periods resulting in possible

overcharged billing statements or the loss of previously accounted hours that would otherwise be

available for the independent contractors.​ Our project aims to relieve the challenges faced

between the clients and contractors by resolving billing inconsistencies and rectifying time

reporting instability. In an attempt to mitigate these issues, we are creating a web-based

application that serves as a portal with administrative controls for Freedom Makers to manage

client-contractor billing relations, including a real-time reporting system with a clock-in,

clock-out feature for contractor use.

T​he project is intended for the internal billing team of Freedom Makers, Laura’s clients

and independent contractors, which is largely comprised of the military veteran and spouse

community and the independent businesses that support this community. The end goal is to

create a long-term product that has administrative properties which Laura Renner and her

internal billing team may utilize to manage client-contractor billing relationships, track analytical

data for comparison reports, and serve as a client-contractor reporting timesheet with a live time

clock to track real-time work hours and calculate pay period totals.
 
Table of Contents

Introduction

Project Goals & Objectives

Environmental Scan

Feasibility Discussion

Functional Decomposition

Selection of Design Criterion

Final Deliverables

Approach/Methodology

Legal Considerations

Ethical Considerations

Timeline/Budget

Usability Testing/Evaluation

Final Implementation

Discussion

Conclusion

References

Appendix
Introduction

Project Description

Our client Laura Renner, the Founder and CEO of Freedom Makers, is looking to rectify

issues that occur between their prepaid payment plans and contractor timesheet reports. The

issues interfere with their clients’ ability to accurately determine their rolling prepaid hours

between pay periods. We will create a real-time client billing timesheet that allows their clients

to track and manage prepaid hours in live time with their individual contractors. Clients will be

automatically charged based on their set payment plan with Freedom Makers and any additional

hours they did not prepay for in advance. The program, Twinbee, is primarily a web application

that focuses around the Chargebee web API. This will benefit the internal billing team at

Freedom Makers and their billing efficiency between their clients and contractors.

Background

Laura Renner is the Founder and CEO of Freedom Makers, a privately owned recruiting

business in Oakland, California that specializes in business-to-business (B2B) sales offering

other businesses services through the employment and support of military veterans and spouses.

In short, Freedom Makers is a recruiting agency with a mission to provide employment for the

military affiliated workforce. Laura works with military veterans and spouses, whom we will

consider “contractors” or “freedom makers”, and assists them in finding independent contracting

positions or remote work with outside companies which we call her “clients”. Moreover, a

contractor may work with more than one of Laura’s clients, and Laura’s clients can employ

multiple freedom makers.

Issue in Technology

The current billing process between her clients and contractors requires improvement to

guarantee accurate billing for prepaid hours in the interim of pay periods and to avoid

overcharging her clients. Currently, the billing method relies on the honor system and

documentation of an excel spreadsheet between the client and freedom maker. Therefore,

reporting hours can result in unaccounted prepaid hours or accrue additional charges for Laura’s

clients.

Solution to Problem

We envision the solution as a real-time client billing time sheet, which both clients and

contractors may utilize. The project will take place as a web-based application that a user can

access from any internet-accessible device.

Evidence Proposed Project is Needed

Laura Renner reached out via email inquiring of availability to work on her potential

project. She proposed the challenges she faced with her current billing process and stated she had

been actively looking for a solution to resolve these issues since the last year.
Project Goals & Objectives

Project Objectives

● Project uses a Google account authenticator to log in.

● Main page displays a dashboard for different users: admin, clients, contractors.

● Admin page can control (add, edit/modify, delete/remove, manage) the clients and

contractor timesheets and profiles.

● Client page can review past billing history, edit and approve contractor timesheets.

● Contractor page can add, edit/modify, and submit individual timesheets.

Project Goals

● Relieve the time reporting discrepancy between Freedom Maker’s clients and contractors.

● Establish a unified system that allows all parties to manage hours and billing

relationships.

● Resolve potential inaccuracies with rolling prepaid hours between pay periods.

● Ensure a reliable billing system that assures accurate use of new billing period paid hours

that are not rolled over credits.

 
Environmental Scan

This project will be similar to a flexible cell phone billing plan; however, our project is

unique because it focuses on incorporating accuracy and transparency between Freedom Maker’s

clients and contractors. The project strictly accommodates consistency; by consistency, we are
defining this to the correctness of estimated roll-over hours and the arrangement of several

different payment plans that Freedom Makers has for their clients.While similar services are

offered by multiple entities including Chargebee’s competitors, the result is ultimately a product

that requires a great deal of manual configuration on the part of a small business owner that may

be unfamiliar with application configuration (Recurly, 2020). Many similar platforms argue that

their level of professional support is sufficient; however this is of little use to small businesses

that lack the time to effectively learn the intricacies of a new software (Chargify, 2020). As such,

our product aims to be tailored to specific needs as outlined by our client with little manual

configuration.

Our client’s outlook among businesses is unique; Laura has made clear a focus on

transparency, honesty, and fairness in her billing practices that takes priority over enhancing

revenue. This is directly contrary to the general marketing strategy of various billing services. A

brief overview of Recurly’s product page, for example, shows an impressively robust platform

covering retention, flexible integrations, optimations, international support, analytics, and more.

Combined, this provides an attractive option that unfortunately fails to focus on the customer’s

wellbeing. With this in mind, we set out to build a solution that wholly satisfies our client’s

unique needs.

Feasibility Discussion

Functionally, this project leans heavily on Chargebee’s API. While Chargebee offers

customer and admin portals of their own, relying on these would mean our client would need to
manage yet another profile. With the goals of ease of use, transparency, and an overall desire to

“lighten the burden”, the functionality of this system is as follows:

Data Storage

Data storage is split between use of a MySQL server, hosted by Heroku in partnership

with AWS, and Chargebee’s own internal storage. The MySQL server stores basic Freedom

Maker information, Freedom Maker timesheets, and administrator records. Client data is stored

with Chargebee directly. This was done to reduce redundancies with customer data already

collected by Chargebee. A Repository/Service pattern was employed to reduce complexity in

working with this distributed system.

Login

Google’s ubiquitous nature created an opportunity to both reduce the project workload

and improve the user experience by leveraging the official Sign-In API (Google, 2019). Users

do not need to maintain a separate account. By authenticating the token and retrieving the user

directly from Google, this also serves to further secure our product. The user’s browser is

redirected to the page that corresponds to their role of either Admin, Freedom Maker, or Client.

Each page offers a portal for basic operations.

Portals

The Admin, Client, and Freedom Maker portals consist of a “single-page web application” for

each with views dynamically populated with AJAX. All portals make heavy use of tables as each role is

benefited by reviewing multiple records.

 The Admin portal makes heavy use of general CRUD functionality for Clients, Plans,

Subscriptions, Timesheets, and Freedom Makers. This is made possible by the various Admin table’s

interactive functionality; clicking on a record allows for record editing and deletion, while the table itself

offers an option to insert new data. While both the Chargebee API and MySQL offer more advanced

functionality, we have limited Admin abilities to keep the system user-friendly; many of the options,

including billing meta data and advanced sorting options, would only serve to overwhelm.

The Client and Freedom Maker portals offer less interactivity. The Client portal is heavily

focused on billing; while they can view associated Freedom Makers and Timesheets, a Client can only

modify their own billing, profile details, and subscriptions. Similarly, Freedom Makers can view

associated Clients and Timesheets, but can only “Clock In”, “Clock Out”, or adjust their own contact

details. Any modifications must be done by administrators. This restraint is intentional; by focusing the

user experience on only a few core features, we reduce the likelihood of unintentional actions.

Navigator

Each portal contains a personalized navigation menu, dynamically populated from the

backend server with EJS. This design choice provides scalability and flexibility between the

separate portals while maintaining a common aesthetic between them. Scalability is of

paramount concern; while currently each portal is tailored to specific use-cases, our client would

like each portal to offer more content in the future as it pertains to each user type.

Client Billing

The project was ultimately born out of a concern for accurate billing of hours. As such,

we have given clients various buckets in their metadata in order to track remaining hours. The

Freedom Makers’ “clock in” and “clock out” directly correlates to these buckets; with each
“clock out” action, the corresponding Client’s bucket is subtracted by an amount equivalent to

the number of hours worked by the Freedom Maker, allowing for real time statistics, billing, and

notifications. Additionally, by storing a state within variables unaffected by change over time,

we prevent the Client’s hours from ever expiring; thus, allowing us to fulfill another of Laura’s

core concerns.

Functional Decomposition

The functionality of this system was born out of the client’s needs directly. Essential

functionality is broken down into user access, authentication, time tracking, administrative

actions, and client subscription management. Additional functionalities are manifested from

these directly.

Versatile Access

In order to ensure access from most connected devices, the system was to be rooted in a

browser-based web application. This had the additional benefit of requiring only a single set of

API’s for the front and back ends as opposed to multiple lines of development tailored to specific

device types.

Time Tracking

Our client’s concern with accurate billing implied a need for accurate time-tracking, as

Laura deals primarily in time. As such, a general Clock-In/Clock-Out mechanism was needed on

the Freedom Maker’s portal that interfaces in real time with the Clients’ allotted hours.
Record-keeping and verification requirements meant this was not limited to a single

function-call; records of each action would need to be kept in long-term storage.

Rollover Hours

As Laura requested the application be driven by Chargebee’s services, there exists a need

to store her clients’ purchase histories in order to track the number of current available hours

each client has for their Freedom Makers’ use. This is of particular concern and Laura’s driving

force for requesting this project. In order to ensure that Clients are transparently and accurately

billed without losing their hours, a current running total needed to be kept in storage. In addition

to accurate subscription billing, clients would need the ability to purchase additional hours

instantly without affecting their ongoing subscriptions.

Administrative Capabilities

Laura and her team will need the ability to manage the application on their own without

the developers. As such, a fully-featured Administrator page is needed that allows for all facets

of CRUD functionality for each entity and relationship. To stay in line with standard

administrative suites, this has taken shape as a series of submittable forms and tables, providing

the necessary functionality in a familiar format.

Security and Authentication

As a web application dealing with confidential information, authentication and proper

routing were critical. With the Administrator, Client, and Freedom-Maker portals located within

the same domain, a reliable log-in functionality was needed to ensure access control. This same
form of access control was to be leveraged in authenticating consumption of RESTful services.

This authentication was also time-sensitive; it could not interfere with the user’s ability to

perform their tasks.

Selection of design criterion

User friendliness and mobile capability

One goal and emphasis for our application was to maintain user friendliness and mobile

platform capability. Initially when our client reached out to us, Laura expressed that the external

web API she was trying to utilize was not very user-friendly. To ensure user friendliness, we

designed the interface according to our understanding of user operations as an administrator,

client, or independent contractor. Evidently, our core application was not designed as a mobile

application; however, we wanted our application to be accessible and functional via mobile

devices. With this in consideration, our application functions similarly on both web and mobile

browsers.

User Security

The security requirements coupled with the short development time meant a proven

solution was needed. Rather than build proprietary authentication, Google’s Sign-In API was

used. This allowed for both user-based routing and internal API authentication by using

Google’s own token verification system. While this increased difficulties in testing locally due to

Google’s need for an SSL certificate, the reliability outweighed any loss of time.
Cost

While cost was not of critical concern, we aimed to keep overall costs comparable to

consumer-level subscriptions of approximately $20 monthly. Costs largely come from domains

and server hosting. In order to obtain the needed services, the following costs were incurred:

Heroku Live Server Hosting / SSL $7 Monthly

Heroku Test Server Hosting / SSL $7 Monthly

Google G Suite $6 Monthly

Google Domains $12 Annually

With an average cost of $21 monthly, this goal was largely achieved.

Framework

With only 5 weeks to implement this design, a framework with rapid prototyping and

robust API support was needed. Express.js offered this along with excellent API compatibility.

An initial prototype was available by the end of the first week of development.

Final Deliverables

Completion of the project is marked by the release of the product to Laura and her team.

The final product is a web based application where users can enter and track their work hours.

Laura Renner has administrative capabilities to manage her clients and contractor relations.

Since the project is web-based, the platform is easily accessible for anyone with a Google

account and link to the website. The working website is hosted by Heroku allowing for rapid
deployment. Leveraging the integrated services by the platform ultimately allows for a rapidly

deployable and easily expandable product that reduces the time-to-market for our client.

The final deliverable is a long-term product that has administrative properties which

Laura Renner and her internal billing team may utilize to manage client-contractor billing

relationships, track analytical data for comparison reports, and serve as a client-contractor

reporting timesheet with a clock-in, clock-out feature to track real-time work hours and calculate

pay period totals.

Approach/Methodology

In order to accommodate the short timeframe, an Agile methodology was followed with

the aid of the tool Pivotal Tracker. Pivotal Tracker helped ensure weekly work was target,

purposeful, and tracked. Meetings with Laura were held weekly to ensure the product was of

expected quality and function. The meetings also allowed for continuous gathering of

information and clarification of requirements.

Legal Considerations

The general legal considerations were to prevent any leakage of business conduct and

privacy information of any members or employees of Freedom Makers.

As our project heavily relies on the use of the Heroku application for deployment and

Google web APIs, we have conducted further research on potential legal considerations that may

violate user terms (Google, 2019). Further research has reflected that the Heroku platform is in
compliance with GDPR, PCI, HIPAA, ISO, and SOC (Heroku, 2020). Google has the right to

monitor the use of APIs to ensure quality, improve Google products and services, and verify

compliance with Google terms and agreements (Google, 2019).

Ethical Considerations

Freedom Makers aims to serve the military veteran and spouse community. Laura’s

mission to serve this community has the potential to exacerbate military veteran and spousal

underemployment, which is a significant indicator of status and financial injustice. Relatively,

military veterans and spouses struggle with employment in careers within their industry, pay

grade, or qualifications; consequently, most will resort to accepting work or gigs that do not

nurture a career path simply to maintain a regular source of income.

Timeline/Budget
 
Project Timeline

Initial contact with the client Laura Renner took place in mid January 2020. A follow up

date will take place on Monday, April 13, 2020 to set a potential collaboration meeting to ensure

the project is in line with the client’s expectations. Project research will tentatively take place

starting Monday, April 20, 2020. Our first meeting to discuss the project and expectations with

her will take place on Thursday, April 23, 2020, and initial project steps will begin by Sunday,

April 26, 2020 or Monday, April 27, 2020. Laura agreed to weekly meetings to confirm her

expectations and monitor our progress with the project.

 Week 1 Set up Heroku, database, Google Suite, and Node environment. Create Landing

Page, User Page, and Admin/Billing Page.

Week 2 Implement Admin/Billing Page functionality.

Week 3 Implement Maker and Client Page functionality.

Week 4 Set up notification method and verify functionality of classes.

Week 5 Troubleshoot, end-to-end testing, and perform final adjustments.

Upon completion of our project, we can confirm that we were able to successfully accomplish

the tasks according to our timeline or sooner than described above.

 
Budget

Laura Renner plans on offering an estimated stipend of $200 to cover any possible

expenses the project may incur. A survey of the necessary licenses places annual cost at $168; in

line with Laura’s proposed budget. The budget breakdown is as follows:

Domain $12 Annually (Google Domains, estimated pending final domain name)
Registration

G Suite $6 Monthly

Server Hosting $7 Monthly (Heroku, “Hobby” Dyno level)

with SSL
Final Implementation
The final product has been implemented as a series of single-page web applications that rely on

REST services, both proprietary and third-party, to supply the necessary data to power our users’ required

functionality. However, only the proprietary rest services are exposed to the front-end.

Framework

The back-end server was implemented with Node.js using the Express.js framework as well as the

EJS templating engine. This allowed rapid development with limited overhead and minimal file structure

compared to alternatives.

As it was decided to use a single-page application style, Express.js was largely used to route

REST services and authentication. Virtually all communication, both between the front-end and back-end

as well as between two distinct back-end services, took place as HTTP requests using these services. This

approach allowed us to decouple various sections of code for better maintainability.

Services

In order to maintain structure, code reuse, and readability, the backend functionality was

implemented using a service-repository pattern, though the repository was not always possible to use in

the case of third-party integrations. The provided services covered 8 specific use cases; authentication,

Chargebee integration, Clients, Freedom Makers, notifications, relationships between Clients and

Freedom Makers, time clock actions, and time sheets.

Three of the services, the authentication service, Chargebee service, and emailService, work with

third-party API’s to obtain their relevant data and as such have no associated repository. The

authentication service largely relies on Google’s Sign-In API to decode tokens and verifies the owners’
roles within the application ​(Google, 2019)​. This verification is also used extensively to secure the

proprietary API endpoints.

The Chargebee service provides more approachable access to Chargebee’s endpoints as they

pertain to client billing, plans, subscriptions and payments. This service was created to intentionally limit

future developer access to Chargebee’s complex API in order to prevent unintentional actions while

allowing related services to obtain the necessary information (Chargebee, 2020).

The email service is used for notifications to administrators, Clients, Freedom Makers, and

developers. This has been implemented using the common tool Nodemailer in conjunction with Google’s

Gmail service with plans to expand for use with AWS SES (Amazon, 2020).

The time clock service is a smaller service that handles only the user action of “clocking in” and

“clocking out.” The service makes use of Moment.js in order to calculate human-readable

times(Moment.js, 2020). The remaining services for Client, Freedom Maker, Relationship, and time sheet

are largely CRUD driven. These services interact with their respective repositories to both obtain more

meaningful ES6 class objects and to preserve generated data in long-term storage. The objects are in turn

manipulated by the services themselves as needed to provide the application’s core functionalities.

Data Storage

Data storage is split between use of a MySQL server, hosted by Heroku in partnership

with AWS, and Chargebee’s own internal storage. The MySQL server stores basic Freedom

Maker information, Freedom Maker timesheets, and administrator records. Client data is stored

with Chargebee directly. This was done to reduce redundancies with customer data already

collected by Chargebee.
Login

The action of logging in was implemented with Google’s Sign-In API. Google’s

token-based authentication allowed for both enhanced security as well as targeted routing. The

application’s database stores hashed administrator emails as well as Freedom Maker and Client

emails. Once an email is authenticated, the user is routed to one of three portals; Administrator,

Client, or Freedom Maker.

Portals

To accommodate each unique user, we made three separate interfaces as single web

pages. Each portals’ main tab consists of the same structured HTML and CSS to maintain a

consistent layout for future potential features such as news dashboards. Alternative options

presented in the navigation menu are dynamically produced with EJS, thus fulfilling the purpose

of allowing us to present specific functionality and the flexibility to create distinct compositions

via AJAX within the same user page.

With the help of Bootstrap (Bootstrap, 2020), we were able to feature several forms

which use select drop-downs or request user text input. Some of these forms are pre-populated

by the use of AJAX calls. Each portal also features GMT-UTC real time. The time feature was

referenced and attributed the resource W3Schools (W3Schools, 2020). W3Schools was also

referenced to produce the calendar and date time picker that is presented within the Admin

portal.

Although the Client and Freedom Maker portals took on the same style of dynamic

production, these portals’ main tabs react slightly differently. The Client portal’s main tab is
immediately overwritten with an AJAX call. Despite the HTML containing the same structure as

the main page in the Admin portal, the user would never witness this. This was intentional to

later reproduce it’s content on the main tab into a separate additional tab on the navigation menu.

As for the Freedom Maker page, the main tab is hardcoded and not dynamically structured

because of the functionality of the clock button and no expectation of the Freedom Maker portal

to possess a user dashboard. However, this is planned to be restructured as the request for

dashboards on all portals is now ideal.

Navigator

Each portal contains a personalized navigation menu, dynamically populated and

rendered from the backend server with EJS. This design choice provides scalability and

flexibility between the separate portals while maintaining a common aesthetic between them.

Scalability is of paramount concern; while currently each portal is tailored to specific use-cases,

our client would like each portal to offer more content in the future as it pertains to each user

type.

Client Billing

The project was ultimately born out of a concern for accurate billing of hours. As such,

we have given clients various buckets in their metadata in order to track remaining hours. The

Freedom Makers’ “clock in” and “clock out” actions directly affect these buckets; with each

“clock out” action, the corresponding Client’s bucket is subtracted by an amount equivalent to

the number of hours worked by the Freedom Maker, allowing for real time statistics, billing, and
notifications. Additionally, by storing a state within variables unaffected by change over time,

we prevent the Client’s hours from expiring and enhancing fault tolerance.

Conclusion

Our client Laura Renner, the Founder of Freedom Makers, was looking to rectify issues

that occur when billing clients for their prepaid payment plans based on their contractor’s

timesheet records. These issues interfered with their clients’ ability to accurately determine the

rolling prepaid hours between pay periods. To remedy these challenges, we created a real-time

client billing application and timesheet reporting system that allows their clients to track and

manage prepaid hours in live time with their individual contractors. Clients are automatically

charged based on their set payment plan with Freedom Makers and any additional hours they did

not prepay for in advance. The program, Twinbee, is primarily a web application that focuses

around the Chargebee web API. This will benefit the internal billing team at Freedom Makers

and support billing efficiency between their clients and contractors.

Due to timeline restrictions, an Agile methodology was followed with the aid of the tool

Pivotal Tracker. Pivotal Tracker helped ensure weekly work was target, purposeful, and tracked.

We held meetings with Laura on a weekly basis to ensure the product was of expected quality

and functionality. The meetings also allowed for continuous gathering of information and

clarification of requirements.

To limit our scope of design specifications, we based core criteria on ensuring

user-friendliness, user security, cost budgets, and framework efficiency. Our final

implementation includes three unique portal interfaces for administrative, client, and contractor
users. Administrators have full functionality and access to all features, including those exclusive

to the client and contractor portals. Common administrative operations include functions to add,

modify, edit, delete, cancel, and clear an action. Clients are only allowed to edit, review, and

update, whereas contractors can only report and review.

The administrator portal allows the ability to manage clients, manage contractors,

manage available credits, manage plans and subscriptions, manage relationships, and manage

timesheets. The contractor portal features options to update their payment method, pay any

generated invoices, buy instant hours for their available credits, and review their contractor’s

timesheets. The contractor portal has a functioning time reporting system with a

clock-in/clock-out feature. Contractors can also review their timesheets but do not have the

ability to modify them.

From creating TwinBee, we both learned more about our individual skill sets, talents, and

areas of improvement. Upon designing and implementing this application, we both discovered

the amount of dedication, cooperation, and communication involved in creating a successful

product. With an agile software development approach, it is expected to restructure often and be

prepared to show immediate progress or updates to an intended client. Regarding future

implementations, Laura has requested for us to maintain the application and roll out new features

as independent contractors. The duration of this agreement is tentative but is expected to lean

more on a part-time long-term basis.

References

Amazon. (2020) Amazon Simple Email Service. Retrieved from

https://aws.amazon.com/ses/.

Bootstrap. (2020) Bootstrap: The Most Popular HTML, CSS, and JS library In The World.
Retrieved from https://getbootstrap.com/.

Chargebee. (2020) API Overview.. Retrieved from

https://apidocs.chargebee.com/docs/api?lang=node.

Chargify. (2020). Recurring Billing: Subscription Billing Software. Retrieved from

https://www.chargify.com/getting-started/.

Google. (2019) Integrating Google Sign-In into your web app. Retrieved from
https://developers.google.com/identity/sign-in/web/sign-in.

Moment.js. (2020) Moment.js Documentation. Retrieved from https://momentjs.com/docs/.

Recurly. (2020). Subscription Billing and Recurring Billing Platform: Recurly. Retrieved from
https://recurly.com/.

W3Schools. (2020) W3Schools Online Web Tutorials. Retrieved from

https://www.w3schools.com/.
Appendix

A. User Portal Mocks

B. EER Diagram
 C. Usability Test

What is your target audience?

Our target audience should be relatively comfortable with technology, otherwise an

average computer user. The occupations may vary but most will involve administrative work and

the users will be working adults over the age of 18, mostly ranging anywhere from mid-twenties

to late-forties.

Who will be testing your project?

Our project was tested by Laura, the business owner, and Erin, Laura’s administrator.

Laura tested the product as both administrator and client while Erin tested as both administrator

and Freedom Maker.

What are the main tasks you would like your client/group to be able to complete while

testing?

Depending on the specific user (admin, client, freedom maker), the admin can manage all

activities that the client and freedom makers are able to perform. In addition, admins can prepare

subscription plans, manage all clients and all freedom makers, set up working relationships, and

manage timesheets. Clients are able to manage their payment methods, adjust their available

credits, and view their current freedom makers. Freedom makers are allowed to report their

working time by using the clock-in/clock-out feature, review their time records, and view their

current clients.

During testing, our clients tested most of the above functionalities as admins, clients, and

freedom makers. As admins, they should be able to go through an entire process of adding a

client, adding a freedom maker, setting up the client’s subscription plan, and setting up the
working relationship between client and freedom maker. Following this, they should be able to

clock in as the created client and freedom maker. As the client, they should successfully buy

more available credits, adjust their payment method, and view their freedom maker’s time sheets.

As a freedom maker, they should be able to clock in/clock out and see this time difference

reflected in their client’s available credits. They should also see their reported timesheet.

Client-based testing:

Were they able to complete all of the tasks?

Although we needed to quickly fix two small bugs, the client was ultimately able to

complete all tests.

Did they get stuck along the way?

Our client did get stuck twice due to small bugs which we were able to quickly fix. They

were initially uncertain of one functionality, but upon experimenting on their own were able to

‘figure it out’.

What will you do to improve your project in the short term before the festival? In the long

term?

Before the festival, we plan to enhance the user experience by replacing manual text

entry with pickers and simplified dropdowns. Our client has also asked us to support the

platform long term with both bug-fixes and full-feature updates.