From a Replit prototype to a serverless AI hiring platform on AWS

Why we started from the Replit prototype

A lot of projects stall for weeks while everyone argues over a requirements doc. We skipped that. Smartal.ai’s product team had already decided how NeuroHire should look and behave, and they’d done it in a tool they were comfortable iterating in. So our FDE went through the Replit app screen by screen with the founders, mapped each flow to a backend capability and flagged anything a prototype gets away with that production can’t, like hard-coded data, missing auth checks and long-running calls inside the UI.

Getting the FDE embedded and the project off the ground

Our forward deployed engineer wasn’t a ticket-taker sitting off on the side. They joined Smartal.ai’s standups, worked in the client’s channels and made architecture calls with the founders in the room. In the first week they set up the AWS account structure, the CI/CD pipeline and separate dev and production environments, so the client could watch real features land on a live URL instead of waiting for one big reveal.

• Candidate onboarding with AI resume parsing, so Atlas, the matching agent, drafts a profile from a resume in about a minute
• Employer job creation, the applicant pipeline from Applied to Hired, and AI screening with Lyra
• Secure accounts on Amazon Cognito, with email verification and modern sign-in options
• Serverless APIs on AWS Lambda that scale up when a big batch of candidates applies, then back to zero

Keeping AWS costs low without cutting corners

For an early-stage company, cloud spend has to track usage, not ambition. We made every compute path serverless and pay-per-request, kept heavy AI work out of the request path so users never wait on a slow call, and set up AWS budgets and alerts from day one. The platform can absorb a spike after a job post goes out, and the bill drops back down when things are quiet. No idle EC2 instances, no database cluster running at 3 a.m. for nobody.

Week three: a major rework of both user flows

In week three, after putting the early builds in front of real candidates and recruiters, Smartal.ai came back with a big round of changes, mocked up the same way in Replit. These weren’t small tweaks. Both of the platform’s main journeys, the candidate flow and the employer flow, changed in significant ways, and the product picked up a sharper focus on the US market.

• UI updates across both flows: refreshed layouts, navigation and dashboards, so candidates and recruiters each land in a workspace built for them
• Candidate flow: new onboarding paths (resume upload, LinkedIn or a guided step-by-step profile), proctored AI skills assessments with an identity snapshot, and a skills radar with a personalized learning roadmap and best-fit roles
• Employer flow: AI-assisted job creation, where Atlas drafts the posting from a plain-English description, a reworked pipeline board from Applied to Hired, connectors to the ATS tools US recruiting teams already use, and bias and compliance reporting for rules like New York City’s AEDT law
• Field-level data capture: candidate profiles and job postings moved from free-text blocks to structured fields like skills, experience, certifications, location and pay range, each one validated and stored on its own so the AI agents match on real data instead of guessing
• USA only: the platform was restricted to US candidates and employers, with US locations, states and ZIP codes, and compensation in US dollars
• More hiring agents on the employer side: Orion to find passive AI talent from public signals like GitHub, Vela to rank the candidate pool and build a shortlist in minutes, Iris to run adaptive screening interviews and get them on the hiring manager’s calendar, and a compensation agent that benchmarks offers against the US market

Changes that size, three weeks in, are usually where a project slips by a month. This is where the FDE model pays off. Our engineer already knew the codebase, the AWS setup and the reasons behind each design decision. Nobody had to be onboarded and there was no re-scoping workshop. They diffed the new Replit screens against what was live, split the work into candidate and employer tracks, and broke each track into small releases so they could start shipping the same week.

The serverless architecture made a big difference too. Because the backend was already split into modular Lambda functions, the shared pieces like authentication, profiles and AI agent orchestration stayed put. The reworked flows went in as new or updated services alongside them, and we didn’t have to tear out anything that was already working.

The new employer agents are a good example. Each one went in as its own serverless function plugged into the agent orchestration we’d already built, so adding Orion, Vela and Iris didn’t mean touching the screening or matching agents that were already live. And each agent only costs money when a recruiter actually runs a search or a shortlist. The field-level changes worked the same way. We defined each field’s rules once and applied them in both the UI and the API, and the US-only rule is enforced on the backend too, so it can’t be bypassed by skipping the front end.

Our rule was simple. If the client could show it in Replit, we could have it running on AWS shortly after, with real auth, real data and real monitoring.

DJ Computing.IO forward deployed engineer

What made this work

• Clear requirements up front. A clickable prototype beats a 40-page spec.
• One embedded engineer who owns the outcome, not a rotating bench.
• Serverless by default, so cost scales with users, not with headcount.
• Small, frequent releases, so the client sees progress every week.
• An architecture built to change, so a week-three redesign was a re-plan, not a restart.