The starting problem
The founder ran a specialist recruitment firm. She had identified a genuine operational problem in her industry: the tooling used by boutique recruitment agencies to manage candidate pipelines was either built for enterprise (expensive, over-engineered, and slow to adopt) or generic (cheap, but missing the workflow logic that boutique agencies depend on).
She had a clear problem definition, a network of potential early users, and willingness to invest. What she did not have was a technical co-founder or any software development experience.
She had hired a development agency. After six months, she had a partially built application that did not match what had been scoped, a codebase that could not be easily modified, and a total spend of around £45,000 with no path to launch.
The core technical problem was that the agency had built a monolithic, server-rendered application using a PHP framework — a sensible choice in 2015, but the wrong architecture for a lean SaaS product in 2025 with a solo operator needing to iterate quickly. The data model was also wrong: it had been modelled for their existing clients' workflows rather than for the problem the founder had defined.
She came to me at the point where she was deciding whether to continue with the agency, find a technical co-founder, or start over.
My role
I came in as SaaS architect and development consultant. My recommendation after reviewing the existing codebase was to start over — but strategically, not from scratch in the sense of rebuilding the same thing better. The six months of agency work had produced one genuinely valuable asset: a much clearer understanding of what the product actually needed to do.
I scoped a proper MVP: the minimum set of functionality that would allow a boutique recruitment agency to manage a live candidate pipeline from first contact to placement. Nothing else.
The technical decisions
Stack choice was the first decision. The constraints were: a single developer (me, for the build phase), a non-technical founder who would need to operate it independently, and the need to iterate quickly based on early user feedback. The right stack was a React frontend, a serverless API layer on AWS Lambda, a managed PostgreSQL database via RDS, Clerk for authentication, and Stripe for billing. No self-managed infrastructure.
The data model was the second decision — and the most important. The agency's model had been entity-heavy: candidates, clients, vacancies, and applications as separate objects with complex join logic. I rebuilt it around the actual unit of work: the placement pipeline. A pipeline has a candidate, a role, a client, and a set of stages. Everything else is metadata on that object. The model went from twelve tables with thirty-five foreign key relationships to five tables with seven.
The third decision was what not to build. The agency had built, or half-built, an email integration, a document generation system, a reporting module, and a client portal. None of these were in the MVP scope. All of them had consumed the bulk of the six months. The MVP had one job: make it easy to move a candidate through a pipeline. Everything else was deferred.
Authentication, billing, and deployment infrastructure were handled by managed services from day one. I have seen too many MVPs where the founder discovers three months in that their auth layer has security issues, or their billing logic has edge cases. Using Clerk and Stripe from the start meant these were solved problems from week one.
The outcome
The MVP was ready for user testing at week six. The founder ran it with two of her industry contacts — both boutique recruitment agency owners — as informal users.
The feedback from week six to week nine was about workflow details, not architecture. The pipeline stage labels were wrong for their terminology. The candidate status model needed one additional state. The search needed to work across both candidate name and company name. These were all fast changes.
The first paying customer — one of the week-six testers — went on a paid plan in week ten at £149 per month.
By month four, the product had six paying customers with zero churn. The founder has since onboarded a part-time developer to continue building on the codebase.
The founder lesson
The six months of agency work was not entirely wasted. The failed build produced a much sharper problem definition and a much clearer view of what the MVP actually needed. That clarity was directly responsible for how quickly the rebuild moved.
But the lesson about stack and architecture is worth stating plainly: the wrong architecture at the MVP stage costs you iteration speed. A monolithic PHP application with a complex data model is hard to change quickly. A serverless React application with a simple data model is fast to change. When your competitive advantage is learning faster than anyone else, iteration speed is not a nice-to-have.
The other lesson: scope discipline is a skill. The agency had added features because the founder had ideas and they were billing by the hour. A structured MVP scoping process — where every proposed feature gets asked "does the core user journey fail without this?" — is one of the most valuable things a SaaS architect or coach can bring to an early-stage project.