EssayJack: Journey from Prototype to Acquisition

Introduction

EssayJack was an online academic writing software designed to aid students in writing and structuring essays. It offered templates for common essay types, guiding students through the essay writing process using an interactive editor.

Problem: Transitioning EssayJack’s Buggy Prototype to a Scalable Product Ready for Market

EssayJack came to us with a Rails-based 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.

Discovery: Defining a Clear Path Forward

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 the 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?

Envisioning the 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.

Planning: Building the Path from Prototype to Market

We created a plan and roadmap 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.

Team Structure and Collaboration with EssayJack

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.

Implementing Best Practices in Project Management

To improve development efficiency and collaboration prior to starting implementation phase, we incorporate robust project management practices:

• Feature Requests & Bug Reports: We guided the founders on how to create actionable feature requests and bug reports.

• Kanban Workflow: We adopted a Kanban approach for managing tasks, organizing EssayJack’s Pivotal Tracker project board to reflect this workflow.

• Code Reviews & Testing Protocols: All code changes were subjected to code review and tested on a staging environment before deployment to production.

Implementation: From Legacy App Modernization to Fully Institutional App

Laying the Foundation: Modernizing the Legacy App

After completing the technical discovery phase, EssayJack decided to engage our team longer-term to prepare for their MVP launch. Our first step was to take over and modernize the existing prototype, which had some significant technical issues. Key objectives for this phase included:

• Fixing critical bugs that were impacting product demonstrations.

• Establishing a structured project management workflow.

• Extending automated test coverage.

Enhancing User Experience through Bug Fixes

At the prototype stage, EssayJack’s founders were already showing the app to prospective clients, but a few persistent bugs were disrupting these interactions. We prioritized fixing two key issues:

• SASS mixins: The unconventional use of SASS mixins was causing seemingly random page elements to change color on hover.

• WYSIWYG editor: The essay editor was laggy and often failed to capture entered text, which made it challenging to use effectively.

Throughout this process, we logged numerous bugs in EssayJack’s Pivotal Tracker.

Streamlining the Codebase and Optimizing Performance

We also addressed a number of technical distractions and inefficiencies within the codebase:

• Standardization & Modernization: We removed CoffeeScript, eliminated unnecessary subdomains, and standardized naming conventions.

• CI Enhancements: We introduced Rubocop to the continuous integration (CI) workflow to enforce coding standards.

• Database Efficiency: With the help of Bullet, we resolved all “n+1” query issues to improve performance.

Expanding and Integrating Testing Coverage

The integration test suite required updates and additional coverage to ensure key UI features were fully tested. After fixing the existing tests, we added the suite to the CI pipeline to maintain test consistency.

With these improvements, the EssayJack web app was prepared for consistent feature development, bringing us closer to launching a reliable MVP.

Building the 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 Strategy

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.

Fully Institutional Integration: Supporting Educational Licenses

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.

Scaling and Optimization: Ensuring High Availability for Growing Demand

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.

Feature Expansion to Serve a Growing Customer Base

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.

Optimizing the Marketing Website for Lead Conversion

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.

Verification: Sprint Review and User Acceptance Testing (UAT)

To ensure that each new feature aligned with EssayJack’s requirements and user expectations, we established a rigorous verification process incorporating regular sprint reviews and user acceptance testing (UAT).

Sprint Review and Stakeholder Feedback Loop

Every two weeks, our team held a sprint review, presenting completed work increments to the EssayJack stakeholders. This process allowed us to:

• Demonstrate Feature Functionality - Show how new features and updates aligned with project goals and the product roadmap.
• Gather Real-Time Feedback - Capture insights from stakeholders, including the EssayJack founders, who provided valuable input based on their vision and user insights.
• Adapt and Refine - Incorporate feedback to adjust features and ensure they met evolving expectations and practical needs, which was critical in maintaining alignment with EssayJack’s strategic objectives.

This regular feedback loop fostered a collaborative approach, allowing stakeholders, specifically the founder, to have an active role in product development and creating a sense of shared ownership over the evolving platform.

User Acceptance Testing (UAT) for Quality Assurance

In addition to sprint reviews, we integrated user acceptance testing (UAT) at key stages in our workflow. UAT was conducted in a controlled staging environment, enabling stakeholders to interact with and validate new features prior to production deployment. Key aspects of our UAT approach included:

• Realistic Testing Environment - The staging environment closely mirrored the production environment, allowing stakeholders to experience new features under conditions similar to real-world usage.
• Structured Testing Scenarios - We developed structured UAT scenarios based on specific use cases to guide stakeholders in assessing feature functionality and identifying potential issues.
• Issue Identification and Documentation - Feedback from UAT was documented systematically, with identified issues prioritized for resolution. This early detection allowed us to address bugs or usability concerns before they could impact the production environment.
• Iterative Improvement - Post-UAT, any necessary adjustments were implemented, followed by a secondary round of verification if needed. This iterative process ensured the highest level of quality and usability in every release.

Ensuring Stakeholder Confidence in Deployment

By combining sprint reviews with thorough UAT, we created a verification process that minimized risk and enhanced the quality of EssayJack’s product releases. This multi-step approach ensured that every feature was refined and validated before reaching end-users, building trust and confidence among EssayJack’s stakeholders and positioning the platform for reliable, scalable growth.

Through this rigorous verification process, we were able to maintain a high standard of quality, mitigate potential risks, and support EssayJack in delivering a polished and user-centric product.

Handoff & Empowerment: Acquisition and Seamless Transition

With a steadily growing customer base, EssayJack had proven its value to educational institutions. However, the product was increasingly seen as part of a broader educational experience rather than a standalone offering. The natural next step was either to expand significantly with new features or to join forces with a larger EduTech platform to enhance its reach and impact.

This transition took shape when EssayJack was acquired by Wizeprep. Wizeprep planned to integrate EssayJack’s editor into their upcoming platform, Wize Writer, as part of a comprehensive learning tool suite. As a result, further independent development of EssayJack by Hivekind was no longer necessary. Our final goal was therefore to ensure a seamless handoff to the Wizeprep team so they could carry forward the product and the mission behind it.

Key Steps in the Transition

To empower Wizeprep to continue and evolve the EssayJack platform confidently, we took the following steps:

1. Team Onboarding - We collaborated closely with Wizeprep’s product and engineering teams to help them fully understand the product, including its user value, workflows, and core functionality.
2. Integration Development - To ensure a smooth user experience across platforms, we built an integration that allowed users to sign into both EssayJack and Wizeprep with a single login.
3. Codebase and Documentation Walkthrough - Our engineering team conducted an in-depth walkthrough of EssayJack’s codebase, documentation, and systems architecture with Wizeprep’s technical team. This step ensured they understood the foundation they were inheriting and could confidently build upon it.
4. Transfer of Resources and Ownership - We transitioned all accounts, resource access, and ownership to Wizeprep staff, empowering them to independently manage and evolve the platform.

Only when Wizeprep was fully equipped to maintain and grow the EssayJack application did we complete our engagement, leaving them positioned to take the product forward.

Through this seamless handoff, EssayJack’s founders were able to continue their mission of supporting student success, now with Wizeprep’s backing and an expanded platform. This acquisition and transition allowed their vision to reach an even wider audience, with Wizeprep poised to bring new innovations to the EssayJack experience.

Post-Engagement Support: Ensuring Stability and Evolution

Throughout our engagement, we provided continuous support and maintenance to ensure EssayJack’s application remained stable, up-to-date, and responsive to user needs. This included providing advanced technical assistance (known as L2 or L3 support) for EssayJack’s customer success team.

Whenever the customer success team encountered an issue beyond their capabilities, they escalated it to us. These escalations included:

• Configuration Adjustments - Addressing data inconsistencies, often by modifying database entries to correct user data.
• Bug Investigation - Reviewing and addressing issues that impacted the user experience.
• Feature-Related Support - Providing technical insights or adjustments in preparation for upcoming feature releases.

Maintaining and Updating Core Technology

Our maintenance work extended to keeping EssayJack’s core technology stack current, ensuring scalability and security over time. This included:

• Regular Upgrades - Updating Ruby, Rails, Ruby gems, and React.js to their latest stable versions.
• Codebase Refactoring - Refining and optimizing code as the feature set evolved, maintaining performance and readability.
• Legacy Code Management - Removing outdated or unused code to streamline the codebase and improve maintainability.

Through ongoing support and proactive maintenance, we ensured that EssayJack’s platform continued to operate smoothly, delivering a consistent, high-quality experience to users and supporting the application’s long-term growth.

Conclusion: Achieving the Vision and Building a Legacy

Over the course of more than five years, Hivekind collaborated closely with EssayJack, transforming an early-stage prototype into a robust, scalable, and widely respected EduTech product. Together, we achieved the desired future state by evolving EssayJack into a stable and feature-rich platform, ultimately primed for acquisition by a larger organization.

Through our structured roadmap, agile implementation, and seamless handoff, we empowered EssayJack’s founders to reach their objectives as defined earlier in the Discovery phase:

• Stability and Reliability - Transforming EssayJack from a prototype into a stable, high-performing platform with reliable functionality.
• Market-Ready Features - Building and refining features that allowed EssayJack to serve students and educators effectively, leading to widespread adoption.
• Institutional Scalability - Establishing the technical foundation to support educational institutions at scale, enhancing EssayJack’s appeal and functionality for larger deployments.
• [Bonus] Seamless Handoff - Enabling a smooth transition to Wizeprep’s team, with comprehensive documentation and onboarding, ensuring the continued evolution of the product.

As EssayJack joins Wizeprep, the product will continue to support students in their writing journey, bringing the founders’ vision to an even wider audience. Hivekind’s journey with EssayJack stands as a testament to what is possible when expertise, innovation, and commitment to quality converge.