Building a product alone is not harder than building it with a team. It is different. The challenges are not the ones people expect.
The technical side is manageable. The stack is knowable. The patterns are learnable. What actually breaks solo builds is not capability, it is sequence. Jumping to code before the design is resolved. Building backend endpoints before the UI has revealed what data they actually need. Wiring up the frontend before the component architecture has been thought through. Each of these produces work that has to be partially undone, which in a solo context means you are the one undoing it, on the timeline you were already managing alone.
The process I follow is not a methodology with a name. It is a sequence of phases, each one designed to produce decisions that make the next phase faster and more certain. The phases are not rigid gates. There is movement between them. But the order is deliberate, and departing from it has a cost that I have felt enough times to take the order seriously.
This post walks through each phase: what I do in it, what I am trying to settle before moving on, and the mistake that most solo builders make at that stage.
Solo builds do not fail because of technical difficulty. They fail because of sequence. The right phases in the wrong order produce the same result as no process at all.
PHASE ONE: PROBLEM DEFINITION
Every build starts with a brief of some kind. A client description, a personal itch, a product idea, a feature request. The brief tells you what someone wants. It does not tell you what the product needs to do.
The distinction matters because briefs are written from the outside. They describe the desired outcome without necessarily understanding the problem that produces it. A brief that asks for a dashboard is not telling you what decisions the dashboard needs to support, what data needs to be visible at a glance, or what action a user should be able to take in under thirty seconds. Those are the questions that define the product, and they need answers before anything else happens.
My problem definition phase is a set of questions I work through before opening Figma or writing a line of code. Who is using this and what are they trying to accomplish? What is the most important thing they need to do on each screen? What does success look like for a user who has completed their goal? What does failure look like, and how does the product communicate it?
The output of this phase is not a document. It is a clear enough understanding of the problem that I can evaluate design decisions against it. When I am in Figma deciding between two layouts, the question I am asking is which one better serves the user trying to accomplish the thing I defined here. Without that definition, design decisions default to aesthetic preference, which is a much weaker foundation.
A brief tells you what someone wants. Problem definition tells you what the product needs to do. These are not the same question, and conflating them is how solo builds drift.
PHASE TWO: FIGMA DESIGN
Design comes before code. Not as a formality and not as a deliverable to hand off to a future version of myself. As a thinking tool that resolves the decisions that code makes expensive to change.
The Figma phase has two distinct modes that I keep separate deliberately. The first is exploratory: rough layouts, flow sketches, quick iterations on information hierarchy. Nothing polished. The goal is to understand the shape of the product, how screens connect, what lives where, what the user does in what order. I move fast here and I throw things away without attachment.
The second mode is resolving: taking the best version of what the exploration produced and making the decisions that will inform the build. Spacing. Type hierarchy. Component boundaries. Interaction states. Empty states, error states, loading states. This is where I slow down, because the decisions I make here are the ones I will implement, and implementing a wrong decision is more expensive than reconsidering it in Figma.
The most common mistake at this phase is stopping too early. Designers who are also developers are particularly prone to it, because the code is more familiar and more immediately satisfying than working through the edge cases of a design. Stopping before the error states are resolved, before the empty states are considered, before the mobile layout has been thought through, means those decisions get made under the pressure of running code. That is the worst possible context for making them.
PHASE THREE: DESIGN SYSTEM FOUNDATION
Before any component is built and before any backend work begins, I establish the design system foundations in Figma. Colour styles, text styles, spacing values, border radius, shadows. These are the decisions that everything else inherits from, and making them explicit before building anything means they apply consistently rather than accumulating as implicit conventions that have to be reverse-engineered later.
The discipline here is restraint. The foundations I define at this phase are the ones the screens I have already designed actually use, not the ones a comprehensive design system would include. I am not building for a hypothetical future. I am capturing the decisions the design already made and making them referenceable.
This phase is fast when the Figma design is done properly, because the foundations are already implicit in the design. Making them explicit is a matter of extraction, not invention. When this phase is slow, it is usually because the design phase was not finished and the foundations are still in flux, which is useful information to have before writing a single line of code.
PHASE FOUR: BACKEND ARCHITECTURE
The backend starts with the data model, but the data model starts with the UI. This is the discipline that most backend-first developers find counterintuitive: the schema should be informed by what the product needs to display and what operations it needs to support, not by what is most natural to model in a relational database.
I work through the Figma designs screen by screen and ask what data each screen needs. What entities need to exist. What relationships between them the product requires. What queries the UI will need to run. A dashboard that needs to show aggregated data from three related entities is telling me something about my schema that a database-first approach might not produce.
From there I define the layer structure: Core entities and interfaces, Application services and validators, Infrastructure repositories and persistence, API controllers and middleware. The structure is consistent across every project, which means the architectural decisions are not remade each time. The only decisions that change are the domain-specific ones, which are the decisions the current project actually requires.
The mistake at this phase is building more than the current design requires. Endpoints that no screen calls. Relationships that no feature uses. Schema flexibility added in anticipation of requirements that may never materialise. Every addition that is not driven by a concrete UI need is technical debt paid in advance, and solo builders cannot afford to service debt borrowed against a future that is not guaranteed.
PHASE FIVE: API DESIGN
API design is a translation layer between what the backend knows and what the frontend needs. Done well, it means the frontend receives data in the shape it needs to display, without transformation logic living in component code. Done poorly, it means the frontend spends its time reshaping data that the API could have shaped correctly the first time.
I design API responses by looking at the Figma screens and asking what each screen needs in a single call. A screen that shows a user profile with their recent activity and their current status does not need three separate API calls. It needs one endpoint that returns all three things together, structured the way the UI expects them.
This phase also establishes the DTOs that cross the boundary between backend and frontend. I define these explicitly and mirror them as TypeScript types in the frontend codebase. The same name on both sides. The same shape. When the backend changes a response, the TypeScript type changes, and the compiler surfaces every frontend file that depends on it. That is the contract that makes refactoring safe.
PHASE SIX: FRONTEND IMPLEMENTATION
The frontend starts from the design system foundations already established in Figma and translates them into code. Tailwind configuration mirrors the spacing and colour decisions from the design system. Component structure mirrors the component hierarchy from the Figma file.
I build components in order of dependency: the most atomic first, the most compositional last. Buttons before forms. Forms before pages. Pages before layouts. This order means that when I reach the compositional layer, the building blocks are stable and I am assembling rather than debugging.
The lib/api layer is built in parallel with the components that consume it. Each function maps to one endpoint, named for what it does rather than the HTTP method it uses. Components call these functions. They never construct URLs directly. When the API changes, one file changes and the compiler finds everything that depends on it.
The temptation at this phase is to extend components speculatively. A table component that also handles sorting, filtering, and export, when the current design only shows a static list. That extension is work that might never be used, built against requirements that might change before they are needed, maintained by the only person on the team for the life of the project.
PHASE SEVEN: INTEGRATION
Integration is the phase where the frontend and backend meet for the first time, and it is the phase most likely to reveal that something on either side was built against an incorrect assumption.
I approach integration screen by screen rather than feature by feature. One complete screen, fully wired, all states accounted for, before moving to the next. This means the first screen takes longer than it would if I were wiring all the happy paths first and coming back to error states later. It also means that by the time the second screen is being wired, every pattern from the first screen is established and reusable.
The loading state, the error state, and the empty state for each screen are part of the definition of done for that screen. A screen that works when the API responds successfully but shows nothing meaningful when it does not is not a finished screen. It is half a screen, and the half that is missing is the half the user sees when something goes wrong.
Integration is not done when the happy path works. It is done when every state the screen can be in has been designed, implemented, and tested.
PHASE EIGHT: DEPLOYMENT
Deployment is not the end of the build. It is the beginning of the feedback loop. But it is a phase that solo builders frequently delay longer than they should, because the product never quite feels ready and there is always one more thing to polish before it goes live.
The discipline I apply is to deploy early and deploy often. Not to production users necessarily, but to a real environment where the product can be tested against real conditions: real network latency, real device performance, real data. The gap between how a product feels in a local development environment and how it feels in production is significant enough that closing it early produces better decisions than discovering it at the end.
Deployment configuration is established at the start of the project, not the end. Environment variables, database connections, build pipelines. Setting this up early means that every phase of the build happens against a deployable target, and the final deployment is a repetition of something already done rather than a new and uncertain step.
THE PRINCIPLE THAT MAKES THE PROCESS WORK
Every phase in this process exists to produce decisions that protect the phases that follow. Problem definition protects design. Design protects architecture. Architecture protects implementation. Implementation protects integration. Integration protects deployment.
When a phase is skipped or rushed, the cost does not show up immediately. It shows up in the phase that depended on the decisions that were not made. An integration that keeps revealing mismatches between frontend and backend is telling you the API design phase was not finished. A backend that requires frequent schema changes is telling you the problem definition was not specific enough to inform the data model.
The process is not a guarantee against those problems. It is a discipline for catching them at the cheapest possible point, before they are embedded in running code that has to be partially undone and rebuilt.
Solo building is manageable when the phases are respected and the sequence is honoured. It becomes exhausting when the phases blur together and the same problem gets solved twice: once badly in the wrong context, and once correctly after the cost of the first attempt has already been paid.
CLOSING THOUGHT
The tools in this process, Figma, .NET, Next.js, TypeScript, are not what makes it work. What makes it work is the order. Any sufficiently capable stack applied in the right sequence produces a product that holds together. The same stack applied without sequence produces a product that works today and resists change tomorrow. The process is the product, as much as the code is.