Shipping full-stack, end to end
How I take a web product from empty repo to production URL — and why thinking across every layer makes me a better teammate, not a lone wolf.
Some of the most useful work I've done has been on side projects where I owned every layer — schema, API, UI, deploy. Not because I prefer working alone (I don't), but because seeing the whole pipeline changes how you think about each piece. The bottlenecks move. The hard parts aren't usually the ones you'd expect.
The schema is the spec
I used to start with wireframes. Now I start with a schema.prisma file. The data model forces decisions you'd otherwise defer:
- What's a user? Is a "dealer" a different table, or a role?
- What can be null? What's actually required?
- Which fields are indexed, and what are the access patterns?
Once the schema is right, the API surface practically writes itself.
API before UI
I write the endpoints next — even if I have to mock most of them. The shape of the request and response constrains the frontend in a useful way: you can't design components around data you don't have.
This is where I lean on NestJS for anything non-trivial. CQRS-style separation of read queries from write commands sounds heavy for a small project, but the moment a feature grows a second consumer — or a second developer — it pays for itself.
UI is the easy part
Genuinely. Once you have a typed API client and a real database returning real data, the UI is mostly composition. I reach for:
- TanStack Query for server state — caching, retries, optimistic updates
- shadcn/ui or Material UI for primitives I don't want to rewrite
- Tailwind for everything else
The frontend feels small because all the hard decisions already happened upstream.
Deploy is a feature
A project isn't done until it's live. I deploy early — usually before the UI is presentable — because the deploy itself surfaces problems no local environment will:
- Environment variables you forgot to set
- CORS rules that work on localhost and nowhere else
- Migrations that ran in dev and need to run in prod
Netlify for the frontend, a managed Postgres for data, GitHub Actions to glue it together. Boring infra is the right infra — especially when reliability matters more than novelty.
Why end-to-end thinking helps in a team
The reason I push myself to work this way isn't to avoid collaboration — it's to be better at it. When you've debugged a slow query, a flaky deploy, and a confusing component in the same week, you stop seeing "backend problems" and "frontend problems." You see one system.
That carries straight into team work:
- I write API contracts the frontend can actually consume, because I've been on the receiving end.
- I notice when a schema decision is going to make the UI awkward three sprints from now.
- I can pair across the stack instead of throwing tickets over a wall.
Owning the whole pipeline alone is uncomfortable in a useful way. It builds the empathy and shared vocabulary that make working with designers, backend engineers, and platform teams much smoother. The skill isn't shipping solo — it's seeing the whole picture, whoever you're shipping with.