Custom software development with a production bias

For startups and scale-ups that need the build owned by someone who has shipped.

Product engineering for teams that need a senior builder, not a multi-layer outsourcing chain.

You leave with

Production system

Running software on a stack the team can operate (typically TypeScript, Next.js, Node.js, and a cloud you already use).
Contracts: types, APIs, and content models – not only screenshots.
CI/CD and a deployment path that is not a named person.
Documentation the next engineer can use without a tour.

See it done

HARTMANN · Healthcare pages on XM CloudNext.js components editors compose themselves Zentact · Merchant portalWhitelabel embedded payments beside Adyen Nordic Learning PlatformOne product for leadership, teachers and students

See more details

I design and build custom software for companies that need a production system, not a demo. The work is full-stack: product surfaces in React and Next.js, services and APIs in Node.js, data, CI/CD, and the operational path that keeps the system predictable under real traffic. I take end-to-end ownership – discovery, architecture, implementation, and reliability – so you are not coordinating a designer, a frontend vendor, a backend vendor, and a 'DevOps person' who never met the domain. This is independent delivery: one senior engineer (and, when needed, a small circle you already have) instead of a large bench. I will also tell you when you should buy a product or write a boring script instead of commissioning software.

Who this is for

Startups and scale-ups that need a product path owned by someone who has shipped before.
SMEs whose internal team cannot absorb a new system without senior help.
Companies integrating payments, CMS, CRM, or AI into an existing product.
Teams that have a design or a vendor and need the engineering to actually land.

Problems this engagement solves

The roadmap is clear enough, but delivery keeps slipping in the integration layer.
The current build is a patchwork of agencies and no one owns the contracts between parts.
You need a vertical slice in production before you fund the rest.
Buy-vs-build was never actually decided; the custom work started by default.

What I build

Product interfaces and design-system-grade UI that editors and users can run.
Typed APIs, services, and automation backends.
Headless content platforms on Next.js – including migrations from live CMS stacks.
AI-backed product surfaces with contracts, guardrails, and a fallback.
Payment, CRM, and partner integrations that have to survive vendor failure.

How delivery actually proceeds

A focused implementation starts with the smallest slice that proves the risky assumption – auth, a money path, a content model, an AI contract – then expands behind stable interfaces. I do not start a six-month build on an untested integration. Phased releases keep operational cost visible. If the slice fails, you have spent a bounded amount of money, not a rewrite budget.

Build, buy, or integrate

Custom software is expensive. The job is to spend that cost only where uniqueness actually pays.

Buy when the workflow is a commodity

Auth, billing, email, feature flags, and most CRMs are products. Building them from scratch is rarely the constraint your company will win on.

Integrate when a vendor already owns the domain

Payments, CMS, and LLM inference are better consumed as APIs – with your contracts and observability around them – than reimplemented.

Build when the workflow is the product

If the user-facing path, the data model, or the orchestration is how you compete, that is the custom work. Keep it thin at the edges.

Delete when the feature exists to impress a slide

If no one can name the constraint it removes, it should not be in the backlog. I will push to remove it.

How custom builds usually fail

Starting with a platform instead of a vertical slice.
Hiding vendor lock-in behind a 'hexagonal' layer that nobody maintains.
Treating design mockups as a specification for data and failure modes.
Optimizing for the happy path and discovering retries at 3am.

Fragen, die gestellt werden

Do you work as a one-person development company?

Yes, for focused product and platform work. I am not an outsourcing bench. If the scope needs a team, I will say so before we start rather than grow a hidden chain of subcontractors.

What stacks do you actually ship?

TypeScript across the board. React and Next.js on the client. Node.js (NestJS, Express, tRPC) on the server. PostgreSQL, MongoDB, Redis. AWS, GCP, and Vercel. Headless CMS platforms including Contentful and Sitecore XM Cloud. I will not pick a novelty stack to make the case study interesting.

Scope a build against the real constraint

Send the system you have, the date you cannot miss, and the part that is currently a guess.