The studio
Two mastheads, one shop: work we're hired for, and work we publish ourselves
Filed by the studio · engineering & product · no bylines, because everyone touches everything
“Ship the boring infrastructure well before you ship the flashy feature at all.”
Most studios pick a side: an agency that ships client work and clocks off, or a product shop that quietly stopped taking briefs. We kept both, on purpose. Client engagements pay for the kind of unglamorous rigor — testing, monitoring, documentation — that's easy to skip when nobody's watching. Our own products are where that rigor gets tested on ourselves first, before it ever reaches someone else's roadmap.
The two halves trade lessons constantly. Patterns that hold up under a client's traffic get folded into how we build for ourselves; habits we'd never inflict on a client — the shortcuts, the "we'll fix it later" — don't survive contact with our own on-call rotation either. It keeps the practice honest in both directions.
We work in ink, not slideware: fewer decks, more running code, and a bias toward the plumbing that keeps software alive after launch — the part most pitches skip.
Practice
Product engineering
Surfaces
Web · mobile · cloud
Engagement
Project or retainer
Work
Client software & our own products
What we build
Client workClient work covers the full stack of a platform, not just the parts that demo well. Four beats, and most engagements touch more than one of them.
- Web & mobile apps
- The interfaces people actually touch — browser and native, built to a client's brand and shipped to a client's users.
- APIs & integrations
- The seams between systems: services, webhooks, and the third-party plumbing that has to keep working quietly, every day.
- Cloud infrastructure
- Environments, pipelines, and the account and access hygiene underneath them — built so a client can hand it off, not just hand it over.
- Data plumbing & operational tooling
- The unglamorous middle: migrations, jobs, admin panels, dashboards — the tooling that keeps a platform operable long after launch day.
How we work
4 stagesListen & scope
Workshops and audits to find the real shape of the problem before we write a line of it down as code.
Design & architect
Systems, interfaces and data models, sketched and argued over before anything gets poured in concrete.
Build & ship
Iterative delivery in pieces small enough to review properly and reverse if one of them is wrong.
Operate & support
Monitoring, on-call, and the slow accumulation of fixes that make software boring in the best way.
Our own products
The shopAlongside client work, we design, build and run a small shop of our own SaaS products. No names here — this page is about the practice, not the pitch deck — but the shape of it is consistent: software we needed ourselves, kept small enough that we still answer the support email personally.
It's the other half of the trade with client work. Client engagements keep the practice grounded in real deadlines and real users who aren't us; our own products keep it grounded in the unglamorous long tail of running software — the renewals, the edge cases, the three-in-the-morning page — because we're the ones who live with the consequences.
- Scope
- Narrow on purpose — a small shelf we can actually keep, not a portfolio we quietly abandon.
- Dogfooded
- We run our own products in production against ourselves first. If something breaks, we're the ones paged.
- Funded by the practice
- Client work pays the bills, which means the shop answers to users, not to a fundraising deadline.
Get in touch
One inbox, no formsGot a brief, a platform that needs saving, or an idea worth adding to the shelf? We'd rather hear about it directly than route you through a form.
hello@bnc.rocks