$

Discipline is the product.

Most of what separates a codebase that is pleasant to work in from one that is not comes down to conventions being enforced by machinery rather than remembered by people. This is standard on every project we run.

• One command to a running application. Database reset, fixtures loaded, working credentials printed. No setup wiki, no asking a colleague.
• Fast, deterministic test suites. Fixtures rather than factories, parallelised system tests, coverage enforced per layer instead of one flattering average.
• Nothing is retried to make it pass. A retried test is a broken test with the alarm disconnected.
• Conventions in CI, not in a document. Lint rules, custom cops, failing builds. Anything that only lives in a style guide drifts.
• Migrations checked before they merge. Schema changes are the most common way to take production down.
• Decisions get written down, including the ones that look wrong and are deliberate. That is the part nobody writes down and everybody needs.

What that looks like on an average project.

$ bin/setup

  database      dropped, created, migrated
  fixtures      loaded, 2 tenants, every role
  credentials   owner / admin / staff / customer

  ready on http://localhost:3000              4.1s

$ bin/test

  models          1,284 assertions            1.9s
  jobs              212 assertions            0.6s
  controllers       891 assertions            3.1s
  mailers            96 assertions            0.7s
  system (rack)     340 assertions   12w      6.4s
  system (js)        54 assertions    4w      9.2s

  2,877 assertions, 0 failures, 0 skipped       22s
  coverage  models 100%  controllers 100%  jobs 100%

Representative, not a target. Seconds, not minutes, and that is deliberate. A suite that takes twenty minutes stops being run, and a suite nobody runs is decoration.

How we operate

Nobody here manages anybody.

We do not hire people in order to manage them. No delivery manager, no ceremony, no status meeting that exists to reassure someone else. You get the problem, the context and the access.

It fails immediately with anyone who needs to be told what to do next, which is most of what we screen for.

• Four is the size we aim for. Six is the ceiling. Past that the coordination cost eats the gain and someone has to start managing. We would rather turn work down than staff past it.
• Explain every character you commit. Not what it does, why it is there. Why is the question that matters here.
• A comment explaining what code does is evidence the code does not say it clearly enough, and it goes stale while the code keeps running. If it needs a comment, rewrite it.
• We do not build waste. If we cannot see who uses a feature, we will ask before building it. Code that ships and is never used costs more than code never written.
• Most codebases carry a lot that nothing calls and nobody would miss. Deleting it beats improving it.
• No defensive code for things that cannot happen. Guards around values the system already guarantees are noise that hides the real failure modes. Simple beats clever, and boring beats new.
• It runs on your machine, in seconds. If getting to a running application is slow, everything after it is too.

Agents

We use agents. The standard did not move.

We use coding agents where they earn their place, and our repositories carry written briefs for them. It has made us faster on the mechanical work. It has not changed what we are willing to ship, and the reason is worth stating plainly.

Generated code is fluent whether or not it is correct. It compiles, it reads well, it passes the tests that already exist. That removes the signal experienced reviewers have always relied on, which is that bad code usually looks bad. So the discipline has to carry the weight instead.

• If you cannot explain why a line is there, it does not matter what wrote it. It does not ship.
• The suite is the specification. Not a ticket, not a description of intent. Something executable that cannot be satisfied incorrectly while appearing satisfied.
• Speed became correctness. A twenty minute suite means nobody verifies intermediate work, so failures arrive buried in a batch rather than attached to a change.
• Agents are strong on contained, well-specified changes and weak where the difficulty is deciding what should happen. The interesting work did not move.

Teams with real test discipline get faster with this. Teams without it get faster at producing unverified change, which feels like acceleration for about a quarter.

Stack

What is actually in production.

Languages

Ruby, JavaScript and TypeScript, Python, Swift, Kotlin, SQL, Bash. Rails because it is the best of what we have used, not out of loyalty

Backend

Rails, Node, PostgreSQL, Redis, Sidekiq, Solid Queue, GraphQL and REST

Front end

Hotwire, Turbo, Stimulus, Sass, React where a codebase already has it. Barebones by default

Mobile

Native iOS in Swift, native Android, on-device computer vision, speech recognition, push infrastructure, in-app purchase

Payments

Multi-gateway routing, sub-merchant settlement, double-entry ledgers, reconciliation, open banking, on-chain rails

Infrastructure

Cloudflare Workers and R2, Heroku, AWS, DigitalOcean, Neon, Supabase, Kamal. Containers when a client requires them, never as a default

Data

PostgreSQL, Redis, DuckDB, Elasticsearch where search demands it, Python for analysis and pipelines

Testing

Minitest, RSpec, Capybara, Selenium, VCR, WebMock, parallel system tests

Quality

RuboCop with project-specific cops, Brakeman, Bullet, Rack::Attack, migration safety checks, Sentry and Datadog

Agents

Used where they help, held to the same standard as anything else. Written project briefs in every repository, and nothing ships on the strength of looking right

Localisation

Fully bilingual applications, key parity enforced in CI