Ta strona jest po angielsku. Nie ma jeszcze tłumaczenia; kanoniczny jest adres angielski. Otwórz wersję angielską

Custom software development with a production bias

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 boutique 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.

What you leave with

  • 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.

Wybrane projekty

  • ZentactZarządzany SaaS dla operatora płatności: wszystko, czego potrzeba do przyjmowania płatności, w prostej platformie od razu gotowej do użycia.
  • Nordic Learning PlatformSmart Learning Platform: narzędzia dla kadry zarządzającej, nauczycieli i uczniów na ścieżce nauki.
  • KwizieGeneratywne quizy z dowolnego korpusu wideo — od wielogodzinnych MOOC-ów po krótkie nagrania ze smartfona.

Powiązane usługi

  • Software engineering consultingSenior engineering judgement for companies that need a principal-level partner, not a staffed agency team.
  • Software architectureSystem design for live products: what should exist, where the boundaries sit, and how the system fails.
  • AI integrationPut a model inside an existing workflow, with contracts and a way out — not beside the product as a chatbot.
  • Legacy modernizationMove a live platform onto a current stack in stages, with data integrity, instead of a big-bang rewrite.

Powiązane notatki

Pytania, które padają

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.