APPROACH
AI gives us speed.
We give it direction.
We use AI extensively to explore, build and refine.
Experience, judgment and taste determine what is worth building, what can be simplified, how it feels to use and what is ready to ship.
TWO DIFFERENT QUESTIONS
AI in how we deliver. AI in what you get.
Both belong in the story. We keep them apart so neither is oversold.
How we deliver
AI is central to how Codewrights works. It lets an experienced practice explore more options, build faster and refine further than the hours would otherwise allow. What ships is still decided by people who are accountable for it.
What goes in your app
AI features in your application are chosen according to the actual business need. Sometimes that is a lot. Sometimes the useful answer is a well-made form and a rule. We will tell you which.
HOW AN ENGAGEMENT RUNS
From how the work happens to keeping it running.
We work forward-deployed: on contract, inside your business, building against how the work really happens. Low project-management overhead is the point. You talk to the people doing the work.
Understand the business
We start with how the work really happens: who does what, what customers hear and when, and where it goes wrong today.
Choose the useful first release
Not everything at once. The first release is the smallest one that changes a working day.
Connect the services
We build what belongs in your app and connect the outside services worth keeping.
Handle the edge cases
A failed payment, a customer who isn’t home, a reply nobody expected. Each gets an owner and an outcome, never a silent failure.
Know what is ready to ship
Each workflow has a written definition of done. It becomes tests before the workflow counts as finished.
Keep it running
Releases, monitoring, backups and changes stay with us after launch.
WHO DECIDES WHAT
You run the business. We own the technical work.
Yours
Business decisions and commitments: what you sell, what you promise customers, what you spend.
Ours
Technical judgment, implementation and operation within the engagement, so you are not coordinating a software stack.
RULES FROM A REAL BUILD PLAN
What “done properly” looks like.
These are the delivery rules from the pest-control case study, unedited. Every plan gets its own.
- Company facts, plans, clauses, templates, rules and brand tokens are data. No company literals in code.
- Money is integer cents, and every money row carries the processor’s id.
- Every state change writes an event in the same transaction. Timelines and automations read events; they never infer history from current state.
- Nothing customer-facing sends without a rule or a person, consent for that purpose, quiet hours and a dedup key.
- Jobs are idempotent and safe to retry. Webhooks are verified.
- Every message carries a signed, expiring, single-purpose link. Signing in is the exception.
- Roles are checked on the server for every office, technician and rep route.
- Phone-first for technicians, reps and customers; dense desktop for the office.
- Accounts and properties are many-to-many through grants. Every read of a property, visit, report or invoice checks the grant, not just the account.
- Boring infrastructure: Rails, one Postgres database, Solid Queue, one Fly app per environment.
- Every tenant table carries a company id, and a test proves one company can never read another’s rows.
- Each workflow’s acceptance list becomes system tests before the workflow counts as done.
START WITH A CONVERSATION
Tell us what the business runs on today.
The tools, the workarounds, the things that fall through. We’ll tell you what we would build, what we would keep and what we would leave alone.
Start a conversationhello@codewrights.io