Four opinions we don't apologize for.
We have a clear point of view about how to build software that survives contact with reality. None of these are controversial inside our team. Some of them are controversial outside it. That's fine.
We ship the smallest stack that survives production.
Most teams introduce Kubernetes, microservices, and an event bus before they have product-market fit. Then they spend the next two years operating infrastructure they don't need. We pick PostgreSQL, a single deployable, and n8n until it actually breaks — and only then change one thing at a time.
The hidden cost of "future-proof" architecture is that it eats engineering capacity you'd otherwise spend shipping features. A well-instrumented monolith on a managed Postgres handles more load than most companies will ever see. We default to that. We add complexity only after we've watched something specific fail under measured production traffic.
This isn't a religious commitment to simplicity. It's a calibration: the cost of removing complexity later is high; the cost of adding it later is low. So we add it later.
Schemas are non-negotiable, especially with LLMs.
An LLM that returns free-form text is a bug surface. You can't unit test it. You can't reason about it. You can't safely build downstream features on top of it. Every "interesting LLM feature" we've seen ship into production and then quietly disappear had this shape.
Our default is the opposite. Pydantic schemas are the contract. Every LLM call validates its output against a schema before anything downstream runs. Invalid outputs get a single retry with a fix-it prompt; if they're still invalid, they go to a human review queue. They never silently coerce.
If an AI feature can't be unit-tested, it isn't a feature yet. It's a research project. We treat the boundary between those two states with discipline.
We don't build admin panels. We use n8n.
Internal CRUD tools are where engineering time goes to die. Every internal admin panel starts as "a quick form" and ends as a Frankenstein of half-implemented permissions, stale dropdowns, and the one person who knows how to deploy it.
n8n gives us forms, scheduled runs, retries, integrations, and an audit log for free. Better still, the ops team can *read* the n8n flow — they can see exactly what happens to their data. That transparency is worth more than any admin panel UX.
We do build admin panels eventually — when the workflow has stabilized, the ops team has outgrown n8n's form ergonomics, and the requirements are stable enough to justify the engineering cost. Almost always, that point is much later than people assume.
No retainers without a scoped win first.
Every relationship we have starts with a 1-2 week shipped deliverable. We scope it tightly, ship it, and then both sides decide whether to continue. We don't pitch six-month engagements to people who haven't seen us ship anything yet — and we don't sign clients who aren't comfortable evaluating us on output rather than slides.
If we can't show value in two weeks, a twelve-month retainer won't fix it. After that initial deliverable, monthly support for hosting, monitoring, and incremental additions is a yes.
This is partly self-protection: the work we want is the work we'd want to maintain, and you can only assess that by doing the first piece. It's also a filter on which clients we're a good fit for. The clients who say "prove yourself first" tend to be the clients we do our best work with.
If these resonate, we'll probably get along.
Tell us what you're trying to ship.