Project C2X designs, builds, and operates software — whatever shape the problem turns out to need, from the first commit to the fourth nine. And when something you shipped in a hurry starts to buckle, we are who you call.
Something got built fast. It was vibe coded — an AI wrote most of it, it shipped in a fortnight, and for a while it was the best decision anyone made that quarter.
Then real users arrived. Now nobody can safely change it, the person who prompted it into existence has a slightly haunted look, and every estimate starts with “it depends what that function does.”
This is not a character flaw. It is a stage. Vibe coding it into existence was the right call — it is just that the thing that got you here will not get you to the next order of magnitude. That part is our job: taking vibe-coded software to production grade, so it holds up for every user you are about to have and not only the ten who saw the demo.
No reproducible environment, no documented setup, and deploying means one person doing seventeen things in the right order from memory. They are now on holiday.
No tests, no types, no boundaries. Every fix has a fair chance of breaking something unrelated, so the team quietly stops fixing things.
One wide table, a JSON column called data, and four slightly different ideas about what a user is. Reporting is guesswork and migrations are genuinely frightening.
No pooling, no caching, no rate limits, and an n+1 query on the busiest page. It was perfect at ten users. It is not perfect at ten thousand.
Audit
Two to three weeks reading the code and watching it under real traffic. You get a written assessment: what is here, what is load-bearing, what is quietly on fire, and what each fix costs.
Stabilise
We fix what will hurt you soonest — the outage risk, the data-loss path, the security hole — before touching anything cosmetic.
Make it changeable
Types, tests, and boundaries around the parts that matter, so shipping stops being an act of faith. Incrementally, behind the running product. No freeze, no big-bang rewrite.
Hand it back
A codebase a normal engineer can pick up on a Monday, with the documentation and runbooks to match. You should be able to hire against it.
No lectures about how you should have built it. You had a business to start.
Problems do not arrive labelled as mobile work or backend work. They arrive as something the business needs to exist, usually spanning several layers at once. What changes is where you are when you call — at the start, mid-flight, or long after launch.
An idea, a deadline, and no code yet. We design it, build it, and put it in front of real users.
Very little work is greenfield. We build inside the system you already have, including the parts nobody wants to open.
Launch is the start of the expensive part. We stay for the traffic, the incidents, and the second year.
A few of the systems we have designed, built, and kept running. Happy to go through any of them on a call.
A Nordic care-technology company
Residents and staff are located in real time through ultra-wideband positioning hardware, so an alarm reaches the right person in the right room rather than the whole building. We built the Android app the carers use — React Native with a good deal of native work, including dialling straight into the speakerphone in a resident's room — and the backend behind it, which ingests tens of thousands of button presses, position updates, and location events in real time. High availability was the first requirement, not a later one.
A high-growth SaaS platform
Their product found an audience faster than they had planned for, and the AWS bill grew with it. AWS was the right way to launch — managed services, nobody on call for hardware, no ops team to hire first — but at steady traffic they were paying for elasticity they no longer used. We audited the codebase before moving anything, because lifting an application that cannot survive losing a node only relocates the problem: connection pooling, cached read paths, sessions out of process, health checks that tell the truth. Then we shipped it onto Hetzner behind load balancers, with more than one of everything. The monthly bill came down by over 80%.
A global health insurer
Employees could book appointments, read their health records, and reach the wellbeing services their employer was already paying for. React Native on the front, .NET services behind it, delivered by a team of more than ten engineers working to enterprise standards — test-driven development and strict review, because a regulated insurer does not get to skip either.
A photography platform
Photographers needed somewhere to keep large libraries of images, sort and sell them, and put a portfolio online without hiring anyone to do it. We built the mobile apps that sync and upload straight from an iOS or Android device, and a React website builder in the shape of Squarespace or Wix — galleries, layouts, and publishing, aimed at people whose expertise is photography rather than HTML.
A global supplements retailer
Their distributor storefront ran on AngularJS and had become slow and expensive to change. We made the case for React with a working demonstration rather than a deck, then led the rewrite of the whole web app while the existing one carried on taking orders.