Custom software development, in the four shapes it takes: a SaaS product, the back office your team works in, an online store, or the automation between what you already run.
A SaaS is a product your customers reach through a browser and pay for by the month: one system serving many companies at once, each seeing only its own data. That shape is what makes it sellable, and what makes it hard: tenant isolation, billing and permissions have to be right on day one rather than retrofitted at the first hundred customers. We build the whole of it: the product, the billing, the deployment pipeline, and the work of getting it found. A product nobody can find is a hobby, so SEO and GEO, being cited by search engines and by AI assistants alike, are part of the build rather than a service you go shopping for afterwards.
A back office is the private side of your business: the screens your team signs into to add a product, edit a page, check an order or see who owes what. Customers never see it, and it is where most of the working day actually happens. We build it either way round: as the system your company runs on, or as the admin panel added to a site, shop or app you already have. What separates it from a SaaS is who it is for: a SaaS is sold to many companies, a back office is shaped around how yours works, with your vocabulary on the buttons and permissions that match your real org chart.
An online store is three things that have to work together: a catalogue customers can browse, a checkout that takes their money without losing them on the way, and a back office where you manage what is for sale and what has been ordered. We build the store rather than configuring a template, which is the right call when what you sell does not fit the standard product-and-variant mould: bookings, subscriptions, made-to-order, or pricing and delivery that change by region. Payments run through Stripe, the storefront is built to be found, and the code and your customer data are yours from the first commit.
An automation is a job somebody currently does by hand, handed to a machine that never gets bored: copying a figure between two tools, sorting what arrives, reading a document and filing what it says. This is the cheapest of the four to start, because it changes nothing you already own: we connect the systems you have and put AI only where it earns its place. Every run is observable: you can see what happened and why, and anything the model is unsure about goes to a person instead of being guessed at.
Four things we build, and what we build each of them with. Every tool here is one we reach for on real projects. None is on the list to fill it out.
Anything someone opens: a public site, a customer portal, an app on a phone. Next.js keeps pages fast on a bad connection, Rails carries the projects heaviest with business rules, and Flutter builds iOS and Android once rather than twice. FastAPI is the layer underneath, where your data actually moves.
Work that used to need someone watching it. n8n wires the steps that must go identically every time, and Hermes Agent takes the ones needing judgement. Ollama runs the models on your own hardware, so nothing leaves your network when the data is sensitive. Claude Code runs on our side.
Where it runs, where your data sits, and how you hear about a problem before your users do. PostgreSQL is the default because most business data is relational; MongoDB comes out when a record's shape genuinely varies. Hostinger keeps small projects cheap, AWS answers to auditors, Sentry and Grafana catch what nobody reports.
Your product rarely stands alone. Stripe takes the payments, Brevo sends the mail people actually open, and Chatwoot puts support in one place instead of four inboxes. OneSignal handles the push notifications on iOS and Android, which is the part every mobile project needs and nobody wants to build twice. PostHog shows what people did, so decisions come from behaviour rather than opinion.
Most projects here start from one of these. If one of them is yours, the first conversation is short.
It got you to market fast, and now every new feature is a workaround. You are paying per seat for a product you cannot change.
The first version was cheap and is now unmaintainable. Rebuilding it properly is the only quote that does not come back.
The person who wrote it is gone, there are no tests, and every change is a gamble. So nothing changes.
Export from one tool, reformat, paste into the next. Hours a week spent doing what a script does in seconds.
Recognise one? Whether it turns out to be a rebuild, a rescue or an afternoon of automation, what follows is how we would take it from here.
No project starts with an estimate. It starts with a conversation, and every phase after it ends in something you can look at: a scope, a working build, a product in production.
We start with your business, not your feature list: what the process costs you today, who it slows down, and what changing it would be worth. You leave the call knowing whether we are the right people for it, including when the answer is no.
We turn the problem into screens and written user stories, then price the scope against them. You approve a design and a list of what ships before a line of code exists, so nothing is bought on trust alone.
The build runs in short sprints, each ending in a working demo rather than a status percentage. You see progress every sprint and can reorder what comes next while reordering is still cheap.
You get a product that runs in production, the code and documentation behind it, and a team that can pick it up. Solid means finished: tested, deployed and handed over, not a demo waiting on one last fix.
Tell us what you're working with. We'll come back with a scope, a rough shape and an honest read on the effort.
