Process & opportunity discovery
Mapping how the work runs now, where time and errors accumulate, and which steps are genuinely suited to a model. Some of what we recommend is ordinary software, because that is often the honest answer.
AI systems & automation
Work that runs itself, with someone still accountable for it
We look at how a process actually runs, decide where a model genuinely helps, and build the system around it: the integrations, the constraints, the checks and the review step. What you get is a workflow your team can operate — not a demonstration.
Anatomy of a workflow
Every system we build has these parts
The proportions change from project to project. The parts do not: something comes in, a model does the work only a model can do, the result is checked against rules you agreed, and a person decides when the stakes call for it.
- Intake — the trigger and the data the step needs, pulled from your systems
- Model step — the prompt, the context and the constraints, versioned like code
- Validation — schema, business rules and source checks before anything is accepted
- Review — approval queues where judgement or accountability is required
- Delivery — the result written back to the system that needed it
- Exceptions — everything uncertain routed to a person rather than guessed
What we build
Engineering work we take on
Workflow & system design
Deciding the sequence, what each step receives and returns, where the checks sit and who approves what — agreed in writing before implementation starts.
LLM & AI service integration
Connecting to a model provider with the parts that make it survivable: timeouts, retries, cost and rate limits, and defined behaviour when the provider is down or the response is unusable.
Data & API connections
Reading from and writing to the systems you already run — databases, internal APIs, third-party services — with idempotency and sensible handling of partial failure.
Structured output pipelines
Model output constrained to a defined schema and rejected at the boundary when it does not conform, so a malformed answer fails loudly instead of spreading downstream.
Validation & evaluation
Rule checks on every result, plus fixed test cases a change can be run against — so adjusting a prompt or switching a model is a measured decision, not a hunch.
Human-in-the-loop review
Review queues, approval steps and exception handling, with what a reviewer decided captured alongside the result rather than lost in a chat thread.
Multi-step & agent-assisted flows
Sequences where one step's checked output feeds the next, with defined boundaries and a stopping condition — not an open-ended agent left to improvise.
Monitoring & ongoing improvement
Visibility into what ran, what failed and what was corrected, so the rules can be tightened where reality disagreed with the design.
Concrete examples
The shapes this work usually takes
Described as processes rather than industries, because the same system serves a publisher, a retailer and an operations team.
- Structured data into reviewed output
- A recurring dataset becomes a drafted report, summary or listing, checked against the figures it came from and approved before publication.
- Classifying and routing incoming information
- Messages, tickets or submissions read, labelled and sent to the right queue, with low-confidence cases escalated rather than filed.
- Extracting structure from documents
- Fields pulled from invoices, contracts or forms into a defined schema, with anything ambiguous flagged for a person instead of guessed.
- Research and drafting stages
- Sources gathered and relevant passages extracted into a grounded brief, so drafting starts from cited material rather than recollection.
- AI connected to internal systems
- A model step that can actually read your database and call your APIs, inside an application with permissions, logging and error handling.
- Generation under rules and review gates
- Content or records produced at volume while a schema, a style guide and an approval step decide what is allowed through.
Honest limits
What we will and will not promise
Automation is worth doing where the work is repetitive and the criteria can be written down. Where it cannot, the right system keeps a person in the decision.
-
No autonomy where review belongs
If being wrong has a real cost — publishing, paying, committing to a customer — the design keeps an approval step. We will say so rather than sell a hands-off system.
-
No invented savings
We do not quote percentage improvements or hours saved before running your work through the system. Any number we give you afterwards will be one you can check.
-
Implementation, not model research
Codelab integrates and evaluates models. We do not train or research them, and we operate no proprietary model or platform.
-
Boring technology on purpose
Established frameworks, server-rendered where it fits, dependency-light. The system has to be supportable by your team after hand-over.
The software layer is not an afterthought
Most of what makes an AI system usable is ordinary engineering: the queues, the admin screens, the integrations, the retries, the audit trail. Codelab builds custom web applications, internal operational tools, data pipelines and content systems, and has done long before any of it involved a model. Shopify, Shopify Plus and Liquid work sits here too, where a storefront needs the same treatment.
Stack
Tools we build with
Selected per project against what your team can maintain, not against what is fashionable.
-
Ruby on Rails -
Ruby -
JavaScript -
TypeScript -
React -
Node.js -
Python -
PHP -
MySQL -
PostgreSQL -
Shopify & Shopify Plus -
Liquid
Start a project
Have a process that should be a system?
Describe how it works today, what breaks, and what a good outcome looks like. We will come back with questions and a proposed shape — including the parts that should stay manual.