Rebuilding an EdTech MVP into a production AI training platform

What HeyPractice does

HeyPractice was a sales training platform used by German companies to teach their staff how to pitch. An employee worked through the theory, then recorded a pitch on video or audio, and the platform scored it and returned feedback without a coach having to watch the recording first. Customers bought a workspace, built their own courses inside it, and assigned them to teams. The platform ran in German and English, either on its own or inside a customer's existing learning management system. It is the kind of product we build as part of our EdTech development services.

The HeyPractice rebuild at a glance

• Client

  HeyPractice, formerly Peter Pitch. Dortmund, Germany

• Product

  AI-based sales training platform, sold to enterprises

• Starting point

  A working product with enterprise customers, on a codebase that couldn't carry the next version

• What we did

  Technical audit, application rebuild, AI integration

• Architecture

  Node.js API, React frontend, containers on AWS ECS

• Engagement

  Senior engineering pod, eight people, October 2021 to 2023

Where HeyPractice came from

David Neuendorf founded the company in July 2020 as Peter Pitch. The product was interactive sales training for teams in a room together, and it won enterprise customers early.

Then the market for training people in a room disappeared. The company had already built voice analysis on Google Speech-to-Text and removed it, because recording several people in one room produced audio the model could not read. The product that worked in a training room did not work anywhere else.

The answer was to rebuild the same training method for people working remotely, one person and one camera at a time. That became HeyPractice. The rename happened during our build, in January 2022.

By October 2021 the company had raised a round, had enterprise customers to keep, and had a demo deadline in February. It also had a codebase that had grown past what it was designed for, and no CTO.

What the audit checked, and what we recommended

Before quoting, we audited the repository and the running staging environment. Seven things we look at on an inherited codebase, and what we told him about each one.

• Test coverage

  Enterprise customers were already using the product, and the backend had no automated tests. We recommended covering the business logic first, starting with scoring and access.

• Setup documentation

  The repository had no readme or setup notes. We recommended documenting the setup so new engineers could run the project straight away, since the team was about to grow from two engineers to six.

• Frontend and backend

  Both ran as one application. We recommended separating the API so frontend and backend engineers could work in parallel, and so the same API could later serve a mobile app.

• Application logic

  The logic sat in controllers, where it couldn't be tested or reused. We recommended moving it into separate layers.

• API design

  The API didn't follow REST principles. We recommended rebuilding it to REST before starting the new frontend.

• Load behaviour

  Load had never been tested. We recommended stress testing before the next release, because enterprise customers onboard whole departments at once.

• Hosting and video storage

  We recommended moving to AWS with a CI/CD pipeline, and storing and processing recordings with AWS services, because the AI feedback runs on those recordings.

Rebuilding or repairing the HeyPractice codebase

He asked us to relaunch and improve the software in four to five months. He was evaluating four or five agencies at the same time. Before quoting, we audited the repository and the running staging environment, and compared two options: repairing the existing application layer, or replacing it and keeping the database.

We recommended replacing the application layer and keeping the database. He accepted the recommendation, and the engagement was contracted as a rebuild.

Alongside it we proposed reducing the scope to protect the deadline, deferring teams, community and statistics to a later phase. He kept all three in scope:

“There is no real MVP-approach anymore. We need most of the features because they hardly depend on each other. The core of the product will be pitches/courses/teams. Then dashboard etc can follow.”

The scope was unchanged. The team grew instead, from two engineers in October 2021 to six by January 2022. The ramp is set out in the timeline block below.

What we kept, and what we replaced

This block exists to answer the objection the previous one raises. A prospect who hears “we recommended rebuilding” hears “throw away what you paid for”, and the honest answer is that we recommended replacing about half of it.

• Carried over

  • The database structure, with the models and the migrations carried straight into the new application.
  • The data model, the part of the original build that held up. Keeping it is why a rebuild fitted a four to five month plan at all.
  • The product logic the business had already proven, pitches, courses and the scoring criteria, carried across as behaviour rather than rewritten from a brief.

• Rebuilt

  • The API, rebuilt to REST and divided so it could serve a mobile client later.
  • The application layer, with the logic moved out of the controllers.
  • The frontend, rewritten in React, which is the piece he had already asked for.
  • The hosting and deployment, moved onto AWS with a CI/CD pipeline.

The HeyPractice platform architecture on AWS

• Application

  Node.js served the API. React ran the frontend. The two were built as separate applications, so frontend and backend engineers worked in parallel.

• Infrastructure

  Everything ran on AWS. Containers were stored in ECR and run on ECS. Video and audio recordings went to S3. RDS held the database. SQS provided the message queue. CloudFormation and CDK defined the infrastructure as code. Route 53 handled routing, CloudWatch monitoring, and Secrets Manager credentials. A CI/CD pipeline was set up as part of the engagement.

Scoring a HeyPractice pitch automatically, in German

HeyPractice sells on one promise: a trainee records a pitch and gets scored feedback straight away, without a coach watching the recording first. Delivering that meant scoring speech rather than text, in German, for German enterprises. The client had already tried it once and removed it, because the earlier product recorded several people in one room and the audio was unreadable.

Three vendors evaluated, two shipped, and one integration written off. That is what it costs to put automated scoring into a learning product, and it is the part of AI-based learning platform development that no estimate predicts.

SCORM: running HeyPractice courses inside a customer's LMS

Large companies already run a learning management system, Moodle or similar, and they will not send staff to a second portal to take one course. Enterprise buyers treat this as a condition of the sale.

SCORM is a set of technical standards for e-learning products. It governs how content is packaged and described, how it is launched, how it exchanges data with the host LMS, and how a learner moves between parts of a course. Compliance is what makes content compatible with a customer's LMS.

We integrated Rustici Software to convert course content to SCORM. Employees stay inside their own LMS and sign in with their own credentials, and no user data passes to the training platform.

How HeyPractice protected training recordings

HeyPractice stored employees' pitch recordings. This is how the platform handled that data.

• Hosting

  The platform ran on AWS, with recordings in Amazon S3 and the database in Amazon RDS.

• Credentials

  Credentials were held in AWS Secrets Manager.

• Inside a customer's LMS

  Through SCORM, employees signed in with their own LMS credentials and no user data passed to the training platform.

The delivered HeyPractice platform

A customer can buy HeyPractice's own courses or build its own on the platform, which is a recurring requirement in custom SaaS development.

How the HeyPractice engagement ran

A senior engineering pod, which is a dedicated team of named engineers proposed with CVs before the contract. People joined as the work required them. Frontend and backend engineers worked directly with each other and picked up each other's tasks where that was faster. Slack, Jira and email for communication and tracking.

For the first three months the client had no CTO, so technical decisions were made with a commercial founder. That shapes how a pod has to work: recommendations arrive with a recommended answer and the reasoning behind it.

Results of the HeyPractice rebuild

The rebuilt platform went into production in March 2022, five months after the audit, and the build was finalised that August. At that point HeyPractice reported a 100% return on investment within four months, a 25% rise in employee satisfaction and onboarding time cut in half. The platform shipped in German and English, and enterprise customers including My Second Ear, Lensingmedia and Ergo ran their sales training on it. Development continued into 2023.

HeyPractice technology stack

Node.js, React and AWS: ECS, ECR, S3, RDS, SQS, Route 53, CloudWatch, Secrets Manager, CloudFormation and CDK. IBM Watson Speech to Text, PRECIRE and Rustici Software are third-party services we integrated.