How we build, and what we argue about.

Codebases that outlive the engagement.

Contract work has a failure mode: the contractor leaves and the codebase becomes unmaintainable six months later. Everything below is standard on every project we run, not a premium tier.

One command to a running application

a single command resets the database, loads fixtures and prints working login credentials. A new engineer is productive in minutes, not on day three. No setup wiki, no "works on my machine".

Test suites in the thousands, kept fast

Coverage enforced per layer rather than as a single flattering average. System tests run parallelised, split so the ones that do not need a real browser run fast and wide, which keeps a full suite in minutes and means people actually run it.

Deterministic data

Fixtures rather than factories. Same data every run, faster suites, and no intermittent failures that get re-run until they pass.

Migrations checked before they ship

Schema changes are the most common way to take production down, so the dangerous patterns are blocked automatically rather than caught in review.

Opinions we hold, and will argue for.

Every consultancy says it writes clean code. These are the specific positions that follow from that, including the ones people disagree with. It is better to know now than three weeks into an engagement.

Documentation is fine. Comments usually are not.

A comment explaining what code does is evidence the code does not say it clearly enough, and the comment will drift out of date while the code keeps running. If a function needs a paragraph to explain it, the problem is the function. We reserve comments for the one thing code genuinely cannot express: a constraint imposed from outside the system, where the reason is not visible anywhere in the repository.

Deletion is the best refactor.

Most codebases carry a substantial amount of code that nothing calls, handles cases that cannot occur, or exists because someone anticipated a requirement that never arrived. Removing it is faster than improving it and leaves less to maintain. We look for that first.

No defensive code for states that cannot happen.

Guards, fallbacks and rescues around values the system guarantees are not caution, they are noise that hides the real failure modes and makes tests pass for the wrong reasons. Validate at the boundaries where input is genuinely untrusted. Trust your own code inside them.

Explicit state beats inferred state.

If something is cancelled, store that it is cancelled. Deriving it from three other columns works until the day one of them changes meaning. This matters most where money and compliance are involved, which is where reconstructing what a record meant last March stops being academic.

Simple beats clever, and boring beats new.

The measure is whether someone unfamiliar can change it safely in two years. Clever code fails that test even when it is correct, and a novel dependency fails it whenever the maintainer moves on.

Conventions that are not enforced are not conventions.

They are preferences held by whoever is currently paying attention. If something matters, it belongs in a lint rule, a custom cop, a failing test or a CI gate, where it survives the people who agreed to it.

Sectors we have shipped in, and what runs in production.

Domain knowledge is most of what separates a fast engagement from a slow one. Expand either for detail.

Four sectors have their own pages with the detail: fintech, healthcare, retail and B2B, logistics. All industries.

Industries, in summary9 sectors

Where we have already learned the hard parts.

Domain knowledge is most of what separates a fast engagement from a slow one. These are sectors where we have shipped, and where we already know what the awkward requirement is going to be.

Payments & fintech	Multi-gateway processing, sub-merchant settlement, double-entry ledgers, reconciliation, open banking, crypto rails, chargeback handling
iGaming & prize draws	Real-money entry flows, verifiable prize allocation, identity and age verification, free-entry routes, payout automation, margin reporting
Healthcare & regulated retail	Patient records and health data under HIPAA and UK GDPR, optical and veterinary prescription workflows, prescriber verification and clinical cross-checks, practice management system integration, recall and expiry handling, licence-scoped catalogues, eligibility gating, separate US and EU production regions
Logistics & warehousing	Multi-site inventory, pick/pack/ship fulfilment, stock movement ledgers, distributor catalogues, integration APIs
B2B commerce & wholesale	Quote-to-cash, customer-specific pricing, buying groups, bulk listing and pricing operations, branded buyer portals
Subscriptions & loyalty	Recurring billing, instalment plans, trials and proration, dunning, rewards campaigns, direct debit collection
Applications & onboarding	Multi-step journeys with conditional paths, document handling, third-party verification, operational review queues, audit trails
Drinks & import	Bonded warehouse and duty-suspended stock, importer and merchant catalogues, trade and consumer pricing, allocation and vintage handling, storefront rebuilds for UK wine importers
Consumer mobile	Native iOS and Android, on-device computer vision, speech recognition, push notification infrastructure, in-app purchase, fully localised builds

Stack11 areas

Broad by necessity, not by collecting logos.

Payments work drags in everything around it - queues, ledgers, webhooks, reconciliation, mobile clients, infrastructure. This is what is actually in production across current and past projects.

Runtime & data	Ruby on Rails · Node · PostgreSQL · Redis · Sidekiq · Solid Queue · cron scheduling
Infrastructure	Kamal · Docker · Heroku · Cloudflare Workers & R2 · DigitalOcean · AWS · Azure · Neon · Supabase
Payments	Stripe · Worldpay · multi-gateway routing · sub-merchant settlement · double-entry ledgers · reconciliation
Front end	Hotwire · Turbo · Stimulus · React · Tailwind · server-rendered by default
Mobile	Swift · iOS · Android · APNs · Firebase Cloud Messaging · push notification infrastructure
APIs & access	REST · GraphQL · Devise · OmniAuth · Pundit · multi-tenancy · audit trails
Testing	Minitest · Capybara · Selenium · VCR · WebMock · parallelised system tests · fixture-driven
Quality & security	RuboCop · Brakeman · Bullet · Rack::Attack · automated migration safety checks
Revenue instrumentation	Meta Conversions API · TikTok Events API · browser pixels · attribution from click through to settled payment · programmatic campaign management via platform APIs · product analytics · lifecycle and transactional messaging
Observability	Sentry · Datadog · Skylight · Rollbar · AppSignal
Localisation	Fully bilingual applications including transactional email, SMS and page metadata, not only interface strings · translation workflows · key parity enforced in CI so a missing translation fails the build
Documents & comms	PDF generation · transactional email · Twilio · localisation and translation workflows

How we build MVPs

The usual MVP bargain is that you get something quickly on the understanding it will be thrown away. We think that is a bad trade, and an unnecessary one. An MVP that has to be rewritten is not cheaper - it is the same cost, paid later, with the product frozen while you pay it.

What we build.

• The one loop the product exists to perform, end to end and properly.
• Real payments if money is involved, because a fake checkout teaches you nothing about whether people will pay.
• Authentication, roles, and an admin surface - you will need to operate it from day one.
• The instrumentation to tell whether it worked.

What we deliberately skip.

• Settings, preferences and configuration nobody has asked for yet.
• Edge cases that only exist at a scale you have not reached.
• Abstractions for a second use case that may never arrive.
• Design systems, before there is enough product to justify one.

What does not get skipped is the test suite, the enforced conventions and the one-command setup. Those are what make the difference between an MVP you extend and an MVP you replace, and they cost days rather than weeks. Scope is where you save time. Discipline is not.