Eight shapes of work, and the published case studies sit deepest in the first three: ecommerce and retail, logistics and operations, and healthcare.
Products your customers use
Storefront apps, marketplaces, booking and checkout flows. The things that break in public when they break at all.
Systems your staff use all day
Fulfilment, procurement, scheduling, asset and compliance tooling. Usually replacing a spreadsheet that already encodes the real process.
Integrations between things that disagree
Two systems that both already exist and model the world differently. Most of the work is the reconciliation, not the API call.
Data platforms and reporting
Getting numbers a manager can act on before the month closes, from sources that were never designed to be joined.
AI inside existing products
Retrieval, agents and evaluation wired into a system that already has users, rather than a demo with nothing behind it.
Takeover of someone else’s build
Inherited, stalled, or generated by an AI tool. We read it first and tell you whether it is worth keeping.
Modernisation of what already runs
Rehost, refactor, rearchitect, rebuild or replace. Four of those five are usually cheaper than the one people ask for.
The compliance surface
HIPAA, SOC 2, GDPR and PCI-DSS shape the build. We architect toward them and say plainly that we do not certify against them.
What we have shipped
A list of everything a company can do is not information. Where the work actually is, is.
Ecommerce and retail, 27 published case studies. Checkout flows, stock reservation across stores, returns automation, supplier pipelines and product configurators — most of it on Shopify, three of them published apps in the Shopify App Store.
Logistics and operations, 14. Warehouse fulfilment, vendor operations, asset and service platforms: the systems a business runs on rather than the ones it markets.
AI in production, not in a demo. Clinical skin assessment, commerce agents, contract generation and procurement — each with evaluation and tracing around the model, because that is the part that decides whether it survives real users.
How an engagement runs
We read what exists
The codebase if there is one, the plan if there is not, and the spreadsheet the process actually runs on. You get a written read on what to build, what to leave alone, and what we think should not be built at all.
The first slice that works
Scoped with acceptance tests and, more usefully, stated non-goals. You get working software and a real estimate for the next phase from people who have now touched the code.
Build out, or stop
Each phase priced on its own. Stopping after a phase with something that works is a legitimate outcome, not a failure we design around.
Somebody owns it
Releases, fixes, QA, and a written monthly recommendation on what to build next and what to stop. Most of our engagements are here, some for years.
What founders say after the build
Verbatim quotes from teams we shipped to production. We publish testimonials with written sign-off on file.
“I very much respect the knowledge that you have. You have a lot of things, just in our few communications, that no one else has mentioned. No one else has even made me think about them.”
Mirinda Scott · Founder, AI Change Management
S/SkinOS / 2250.care
“The team treats our roadmap like their own. Every standup felt like working with our own engineers, not an outside vendor.”
PIPixelFox
“They shipped the production version of what our previous agency had been promising for nine months, without the weekly excuses.”
CHCheckyPro
“They told us what NOT to build. That single conversation re-shaped six months of roadmap and saved us a lot of money.”
Recorded client call
“I find him very nice to work with and he actually delivers a very good quality. So I am really happy with him.”
Noa van der Veen · Strategy and operations, CheckyPro
Recorded client call
“You're doing very, very well... the confidence that you're building with me — the full product is what I want to go with.”
“You guys seem switched on and like you know what you're doing. I've got a good feeling about it.”
Dan Cameron · Founder, Self-image
Recorded client call
“You guys take a lot of pride and ownership in the work.”
Hamza Tariq · Co-Founder, GoldenEye
“I had a large project built that needed a very specific understanding and the project was executed perfectly. Great design, great code, no bugs and anything I needed was done incredibly professionally. I would highly recommend and I will definitely be coming back with my…”
“We approached several sellers in our search to get an app developed for our Shopify store. I had a very clear idea in my mind what we wanted and, through [their] expert questioning, [they] absolutely 'got it'. This was further proved through delivery of a…”
“We're working on a Shopify app that retrieves book data from our API and helps online stores and booksellers create book listings faster. This time, we needed to improve the app design and fix functionality issues. In general, we're satisfied with the service and plan…”
“This was a special request where we needed to rush this development. [They] complied and finished everything at the agreed time, and even worked until 2AM [their] local time in order to finish this on time. [They] went the extra mile for us with this…”
“[They were] very patient as we figured out exactly what we needed our app to do. [They were] able to get all the functionality we required, communicated well, and [were] upfront about the cost. We'll definitely be coming back for future projects!”
“Absolutely fantastic work. This was a tricky app, and [they] did great work. [They] really know [their] way around Shopify and the process for developing a Shopify app, which was a great help to me! [They're] motivated and committed, and delivered a very high-quality app.…”
“I am very pleased to have worked with [them]! [They were] very detailed and delivered me perfection in an app! I look forward to working with [them] again!”
“Amazing service. Amazing time. Took all input and made the site great even with minor changes along the way. Will certainly try to use again if I'm lucky enough to have [them] work with me again. Thank you for everything.”
“Very fast and thorough. [They] did exactly what I asked and then went the extra mile to tie up a couple of loose ends. I'm really pleased with the speed and efficiency, and would certainly recommend [them]. Thank you for your help and highly professional…”
“[They understand] the problem so well and deliver the results super quick. I'll not hesitate to say that I've found a gem. One thousand percent recommended!”
“The project was not easy, literally. [They] did hard work on our project and finished as expected. Would like to work on upcoming new features together. Thank you.”
“[They are] reasonable, meticulous, [have] a great sense of design, and [are] very responsive. I really enjoyed working with [them] and [they] delivered a beautiful website for me.”
“Bought this to create a website for my startup company. Results were above and beyond what I was expecting! Quick to answer, and always gave great input and ideas!”
The questions that actually decide whether to talk further.
Anything where an off-the-shelf product would force you to change how the business works. If a SaaS tool fits and costs less than a build, we will say so; that conversation is cheaper for both of us than finding out in month four.
It depends on scope that does not exist until it is defined, so we publish no standing price. What we can do at the first call is tell you which of the bands the market publishes you are likely to land in, and what specifically would move you between them.
Frequently. Inherited codebases, stalled builds and AI-generated prototypes are a large share of the work. It starts with a written read on the code, and sometimes that read says the honest answer is a rebuild of one part rather than all of it.
Mostly TypeScript, React and Next.js on the front end, Node and NestJS or Laravel on the back, Postgres, and AWS or Google Cloud underneath. We inherit whatever a takeover arrives with and are not religious about it.
Small and senior. A typical engagement is one to three engineers who stay on the product, with the person who scoped the work accountable for it. There is no junior padding and no rotating bench.
You do, from the first commit, in your own repositories and deployed to your own infrastructure. That is in the contract rather than in a conversation later.
Tell us what you are trying to build
Or what already exists and is not working. You talk to the engineers who would do the work, not a sales team.