EssayJack: Journey from Prototype to Acquisition

During EssayJack's engagement with Hivekind the product went from prototype, to MVP, to finding its place in the market, and eventually onto being folded into the product offering of a larger EduTech company called Wizeprep. This journey is described here.

EssayJack

EssayJack was an online academic writing software that helped students write and structure essays. This was done through providing templates for common essay types typically required by university courses, and through an interactive editor that guided students through the entire writing process.  

When EssayJack came to us, they had a working prototype of their product. The prototype was a Rails application which captured the core concept of their offering: an essay editor. But the prototype wasn't a viable product. It was missing some major features and already had some show-stopping bugs.

The prototype had been built by a couple of freelance developers. One had already left the project and the other was looking for a way to leave. The EssayJack founders, spurred on by increasing sales opportunities, were at a point where they wanted to transition development of their web app to an agency which could manage both the technical delivery and the product's development. Hivekind's managed teams approach appealed to them.

Members of the Hivekind EssayJack team, with EssayJack co-founder Lindy, at our Kuala Lumpur office.

Technical discovery: A plan forward from the current state

We agreed to start our relationship by performing a technical discovery. This was a one-month engagement that started with us measuring how things currently were, then setting objectives around a desired future state, and finally creating a roadmap to close the gap between the two. We ended by sharing our findings and recommendations in a written report.

Measuring current state

To measure EssayJack's current state we did the following:

1. Analyzed overall code design complexity. We checked if the application was over-engineered and overly complex. We looked at how extensible the codebase was, and if any inefficiencies existed.
2. Considered code maintainability. We looked at how the current codebase measured up against industry best practices. We looked at individual models and services within the code, assessing its purpose and its role within the larger system.
3. Considered current operations and scalability. We reviewed systems engineering and CI pipelines. We looked at how convenient deploying and rolling back changes was. We determined how convenient it would be to scale horizontally if needed.
4. Took a look at security risks. Was EssayJack at risk of exposing personal user data, and what could be done to reduce that risk if necessary?
5. Reviewed third-party integrations. In particular, the payment and subscription management system.
6. Evaluated the testing situation. Was the prototype adequately tested, and if not what were the gaps in test coverage?

Desired future state

To understand EssayJack's desired future state, we sat down with the founders and interviewed them about their future plans for the business. We turned their desires into a list of objectives, which were:

1. To have a stable prototype: new features working as expected at release, and very few (if any) bugs in production.
2. To launch a Minimum Viable Product (MVP): to add the remaining features necessary to start selling EssayJack to students and educational institutions.
3. Founders to spend more time on business development and less time reviewing and testing app features.

Roadmap to close the gap

We created a plan to help EssayJack reach its desired future state. This included:

1. Establishing a process around feature development. Introduce a code review and testing process (via good Git branching practices, Github pull requests, and user-acceptance testing done on a staging environment).
2. Improving the CI pipeline by adding test runs and code quality checks.
3. Establishing a project management workflow for tasks and user stories, and guidance and a template for bug reports.
4. Fixing the currently failing integration test suite, then enlarging its range of tests to ensure confidence that it tested all mission-critical features.
5. Starting deploying new changes to production as soon as they were ready, rather than holding them back and then deploying them in larger batches.
6. Creating a backlog of features needed to launch EssayJack's MVP.
7. With all process improvements in place, implementing the MVP backlog and bringing EssayJack to market.

Legacy app modernization: The right foundation

With the technical discovery complete, EssayJack decided to hire us longer-term to help bring them to MVP launch. We agreed to take over the development of the existing prototype. Even though the prototype had been built recently, it had a number of technical problems that we had to fix right away. We also needed to introduce a proper project management workflow and extend automated test coverage. So the first part of our engagement was a Legacy App Modernization.

The very first thing we did was fix some particularly ugly bugs. Although still at the prototype stage, the founders were showing the app to many prospective clients and these bugs were stopping conversations in their tracks. Two notable bugs we fixed were: the unconventional use of SASS mixins causing (seemingly) random page elements to change color on hover; and the WYSIWYG essay editor being noticeably laggy and not always capturing entered text.

Many bugs on EssayJack's Pivotal Tracker during this phase.

We then introduced healthy project management practices. We taught the founders how to create useful feature requests and bug reports. We adopted Kanban to manage our work in this phase, and so arranged EssayJack's Pivotal Tracker project board to reflect our workflow. All code changes started undergoing code review and being tested on staging before being deployed to production.

We then tidied up some distractions present in the code. This included: removing CoffeeScript, eradicating unnecessary use of subdomains, standardizing naming conventions in the codebase, introducing Rubocop to the CI workflow, and removing all "n+1" queries (with help from Bullet). We also fixed the existing integration test suite, added new tests to ensure it covered key UI features, and then added the suite to the CI pipeline.

With all these changes in place, the EssayJack web app was ready for consistent feature development. We set our sights on launching an MVP.

Minimum viable product: Template editing and user roles

With the modernization done, we had a clear runway to complete EssayJack's MVP backlog.

This backlog wasn't too extensive. The MVP centered on adding two key features: the ability for students to write essays, and the ability for educators to create essay templates. Essay templates were used by the essay editor to guide a student in writing a specific type of essay. The prototype included essay editing, but not template creation. So it was the latter that was the main focus of our backlog.

With template editing came the need to categorize users into different roles. An important part of the plan was to introduce educator, student, and administrator roles to the application, and to give administrators the ability to manage this using an admin tool.

Once the template editor and user roles features were in place, we were able to consider EssayJack "minimally viable". The founders then pursued new business development and client acquisition.

EssayJack's template editor in the run-up to MVP launch.

Product-market fit: A redesign and becoming fully institutional

Launching the MVP let us start bringing customers onto the product. But the real journey was only starting. What EssayJack now needed was a strong indication from the market that their product was useful and valuable. Searching for this is called finding product-market fit.

Although EssayJack had the core features necessary to support students and educators, its look and feel felt dated. The initial design had come about due to necessity and a desire to build quickly. But with more people using the product, feedback was telling us the dated look was turning people away. It was challenging to convince users to use this new, cutting-edge product when it didn't actually look new and cutting-edge.

Frontend redesign and rollout

So in our quest to find product-market fit, we decided the first major step would be to redesign EssayJack's frontend. Together we brought in a design specialist called Digital Natives, who worked iteratively with us to design EssayJack's new brand and UX.

Envisioned new essay editor.

Since we were supporting an existing user base, we approached the redesign with their experience in mind. From the beginning, we were mindful of how we would launch to new and existing users. We came up with the following rollout plan:

1. New designs introduced so that EssayJack users could use either the old interface or the new interface as they preferred.
2. Begin by giving access to the new interface to only a few, selected users.
3. Extend access to all users via a "try our new look" banner. Users would be taken to the new interface but would have the option to switch back to the old one if they wanted to.
4. New EssayJack users placed on the new interface, without the option to use the old one.
5. Encourage users to migrate to the new interface through email campaigns and other initiatives.
6. Turn off the ability to switch back to the old interface, meaning that any users who had migrated to the new one wouldn't be able to switch back.
7. Switch any users still on the old interface over to the new one

Once we reached the point where no users were using the old interface, we removed it from the codebase.

A positive side effect of this plan was that we had to create a first-class EssayJack API. Up until this point, the old frontend was operating against an API of sorts. But it wasn't well defined. To pull this plan off we would have two frontends (the old and the new) interfacing with one single API. Creating this API helped us straighten out a few lingering code design issues, making our backend code and data model better as a result.

Team composition and interfacing with the EssayJack team

During the Product-Market Fit phase, we cemented our working rhythm with the EssayJack team.

Our team was headed by a Product Manager, who was our primary contact point and defined and prioritized our backlog of work. They did this by working with the EssayJack team (primarily the founders) and EssayJack's users to determine what would bring the most value to the user base. The rest of our team consisted of Software Engineers, who implemented the backlog and delivered new features.

We practiced Scrum, with our Product Manager taking the role of Product Owner, and our most senior Engineer taking the role of Scrum Master. We delivered increments of new software every two weeks.

This arrangement freed the EssayJack team up to pursue initiatives outside of product development, including strategy, sales, marketing, business development, and customer support.

Fully institutional

Aside from simply recreating EssayJack's features under a new design, the design work done by Digital Natives outlaid a number of new features, which we implemented after the redesign had been fully rolled out.

The theme of these new features was making EssayJack "fully institutional". We'd learned that there was a stronger business case in attracting educational institutions, who'd purchase licenses for dozens or even hundreds of students at a time.

We made EssayJack able to be integrated with Learning Management Systems (LMS), and introduced features to support an Institution as a core concept within the product.

Product scaling: High availability and code optimization

The redesign and the introduction of institutional features accelerated the adoption of EssayJack. We had found a good fit in the market and so proceeded to prepare the application for scale.

The first thing we did was move EssayJack onto Google Cloud Platform. Doing so allowed us to utilize Kubernetes, and by doing so be ready to scale the application horizontally very quickly if needed.

Ensuring high availability was now a top-level priority. We made sure we could ensure this by introducing a few practices:

1. We made the applications and systems it ran on highly observable, then began monitoring all kinds of information about EssayJack's technical operation using Datadog.
2. We introduced an on-call rotation managed by PagerDuty. If certain information under monitoring moved into a state we considered problematic (e.g. a low number of web requests over the last five minutes), the person on call would be alerted, would respond to the incident, and take action to fix the problem. The PagerDuty setup allowed us to define escalation chains, meaning that if the person on call failed to respond, the next person in the chain would be alerted.
3. We used a log management system to ingest all application logs and make them conveniently searchable. This helped with both monitoring and debugging.
4. We introduced exception tracking via Rollbar. All errors thrown by the application code were captured and made accessible to the development team.
5. We enhanced code quality monitoring by adopting Code Climate.

On top of this hardening of the techniques used to ensure high availability, we also made many performance optimizations to the product itself.

For certain essay types (in particular, ones implemented from complex templates), the initial render of the essay could take up to five seconds. By implementing a caching strategy within the application's codebase and database, we were able to bring this down to near instant rendering.

By analyzing database queries generated by the production application, we were able to see that certain essays had to request large sets of records while loading. By defining appropriate indexes on relevant tables, we were able to reduce query times from more than 3 seconds to less than 0.3 seconds.

The result of this work meant that the same compute resources needed to serve a single classroom of 20 students were then able to serve around 200 students. This allowed us to scale without generating undue extra hosting costs.

Custom software development: Aligning for the next big thing

We had found a strong fit in the market for the EssayJack product and had prepared the infrastructure for scale. What remained was to serve the market we had uncovered, and prepare EssayJack for the next big step, which at the time was considered either another funding round (to drive a significant increase in sales effort) or acquisition.

As EssayJack founders pursued these business development objectives, our team got busy building a whole raft of features to serve our growing customer base. These included:

1. An overhaul of the payment system centered around Stripe's Checkout product.
2. B2C tiered pricing plans for students and educators.
3. An individual educator experience, including course creation and management, custom templates for assignments, and assignment sharing.
4. Introducing EssayJack Courses, which were writing courses created by EssayJack themselves.
5. An essay review feature, in which students could request that their essays be reviewed by a qualified educator, and the extension of this feature to support reviews done by non-EssayJack users.

Marketing website

During this phase, we also extended our responsibilities to include optimizing EssayJack's marketing website for lead conversion. Rather than simply ensure a marketing site was in place, we rebuilt it on HubSpot, then carried out many experiments with content and design, significantly improve sign-up rates.

Support and maintenance

Something that was handled by us during our entire engagement was support and maintenance. This is where we provide higher-level technical assistance to customer success teams, often called L2 or L3 support.

If EssayJack's customer success team couldn't handle an issue themselves, they would escalate it to our team. This may have been a configuration issue (in which we'd adjust database entries until a user's data was correct), a bug report, or information useful to an upcoming feature release.

Maintaining the EssayJack application meant regularly upgrading the core technology used (ruby, Rails, ruby gems, React.js), refactoring parts of the codebase to keep pace with the ever-changing feature set, removing code as it became unused, etc.

Acquisition and hand off

EssayJack had grown a steady customer base, but the product itself felt like just one aspect of a broader experience sought by educational institutions. The next logical step was, therefore, to build significant new features around it, or to become part of a larger product offering from another EduTech company.

EssayJack went on to be acquired by Wizeprep. Wizeprep's plans for EssayJack's editor were to fold it into their (at the time) forthcoming product Wize Writer. This plan meant that further development of EssayJack at the scale currently undertaken by Hivekind wasn't necessary. So rather than continue, we prepared to hand off EssayJack to the Wizeprep team ahead of ending our engagement. We did this as follows:

1. Onboarded Wizeprep's product and engineering teams to EssayJack, showing them how the product worked and how users got value from it
2. Built an integration between the two products, allowing users from one to sign into the other and vice versa
3. Walked engineering through our codebase, documentation, and systems engineering setup, to ensure they understood the application they were taking over
4. Shifted all access and ownership of resources, accounts, etc. to Wizeprep staff

Only when the Wizeprep team was comfortably in control of the EssayJack application did we end our engagement and part ways.

Under Wizeprep, the EssayJack founders were able to continue their mission of helping students write better essays by bringing their vision to a wider audience.

Hivekind and EssayJack's journey together lasted for more than five years. In that time, EssayJack went from a shaky prototype to a top-tier EduTech product worthy of being absorbed into a larger organization.