Full stack development
Applications rather than websites. Next.js and React on the front, Node or Python behind it, with authentication, payments, integrations and a database designed before the first screen is drawn.
When a site is not enough
There is a clear line between a website and an application. A website presents information. An application holds state: accounts, orders, bookings, permissions, things that change and must stay correct when two people touch them at once.
The moment a brief includes the words login, dashboard, subscription, booking or sync, a page builder stops being the right tool. Forcing it produces something that demos well and falls over in month three, usually at the point where the data model should have existed and did not.
Most of my work is still websites. This page is for the projects that are not.
The stack, and why
Next.js with React for anything that needs both good search visibility and real interactivity. Server rendering matters here for the same reason it matters everywhere else on this site: content that only exists after JavaScript runs is content that some crawlers will not see.
Node or Python on the back end depending on what the project touches. Python where there is data work, document generation or scientific libraries in play. Node where the front and back should share types and the team is small.
PostgreSQL by default. A relational database with real constraints prevents a category of bug that no amount of application code fully compensates for.
Deployment on Vercel, Railway or a plain container, whichever the client can actually maintain. I do not pick infrastructure that requires me to stay.
The parts that are easy to get wrong
Payments. Stripe checkout is straightforward until you handle failed webhooks, refunds, proration and the difference between a payment succeeding and an order being fulfillable. I build the webhook handling and the idempotency before the happy path, because that is where the money goes missing.
Shipping and tax. Multi carrier rate quoting at checkout is a latency problem as much as an integration problem. Rates get cached, quotes get a timeout, and the checkout degrades to a flat rate rather than hanging.
Authentication. Sessions, password resets, and the fact that email is not a reliable delivery channel. I use an established provider rather than writing auth from scratch, and I will argue against anyone who wants to write it from scratch.
Integrations. CRM syncs, webhook pipelines and API bridges fail quietly. Every integration I build logs what it sent, what came back, and retries with backoff, so a broken sync is something you find out about rather than something a customer tells you about.
How it connects to the marketing side
The reason I do both is that they keep colliding. An application with no server rendering does not rank. A marketing site bolted onto an app with two different design systems looks like two companies.
So the usual shape of these projects is one codebase serving both: marketing pages that are static and fast, application routes behind authentication, one design system across the two, and one analytics setup that can follow a person from a blog post to a paid account.
Deliverables
Scoped in phases and quoted per phase, so you can stop after the first one.
- 01
Discovery and data model
The entities, their relationships and the constraints, agreed in writing before any interface is built.
- 02
Next.js and React front end
Server rendered where it needs to rank, client rendered where it needs to be fast, one component system throughout.
- 03
Node or Python back end
API routes, business logic, background jobs and a PostgreSQL schema with real constraints.
- 04
Payments
Stripe checkout and subscriptions, webhook handling, idempotency, refunds and the failure paths.
- 05
Integrations
Shipping carriers, CRMs, email, accounting and whatever else the business already runs on, with logging and retries.
- 06
Deployment and handover
CI, environment configuration, a staging environment, and documentation written for the developer who comes after me.
Common questions
Do I need a full application or just a website?
If nothing on the site changes per user, you need a website. The moment you need accounts, saved state, permissions or a transaction that must stay consistent, you need an application. I will tell you which one you are describing, and I have talked people out of the more expensive answer more than once.
Why Next.js rather than a page builder with plugins?
Plugins are excellent until the requirement sits between two of them. At that point you are maintaining glue code inside someone else's architecture, with an upgrade path you do not control. A framework costs more up front and stops costing more after about the third custom requirement.
Can you work with an existing codebase?
Yes, and a good share of this work is exactly that: taking over something half built, or adding a feature to an application whose original developer is gone. I start with a written read of what is there and what it will cost to keep, before proposing anything.
Who owns the code?
You do, in your own repository, from the first commit. I work in your GitHub organisation rather than mine. There is no arrangement where leaving me costs you the source.
What does a full stack project cost?
More than a website and it varies more. A focused application with authentication and payments typically starts around 8,000 US dollars. Anything with meaningful business logic, integrations or multi tenancy goes up from there. I scope in phases so you can stop after phase one if the thing is not working commercially.
Do you do ongoing maintenance?
Yes, on applications I built or have read properly. Dependency updates, monitoring and a response window agreed in writing. I will not take on emergency support for a codebase I have never seen.
Want a straight answer about your site?
Send me the URL. I will tell you what is holding it back and what I would do about it, before you commit to anything.