AI & Agents
Systems that read, decide and act — bounded autonomy with an audit trail.
An AI project is worth the money only if the answer it returns changes a decision. That means the model is the smallest part of the work. Around it you need retrieval, evaluation, guardrails and an interface that keeps a person in charge of the outcome.
Applied AI, built around a decision.
AI development is the work of turning a machine learning capability into software that returns a useful answer inside your own system. It is not a chatbot in a sidebar. It is a scored piece of output, produced on a deadline, from data you own, that someone can act on.
In practice this covers document understanding and extraction, search and retrieval over your own corpus, classification and routing, generation with constraints, and reasoning over structured data. The deliverable is always a service with a measurable contract, not a notebook.
The gap is not models. It is trustworthiness.
Foundation models already do the impressive parts. What remains hard is making the output dependable enough to let a real decision depend on it: correct, cited, refusable when the question is out of scope, and stable as the underlying model changes underneath it.
That is an engineering problem, not a research one. Teams that skip it end up with pilot projects that never graduate. Teams that solve it have software that removes a category of manual work instead of automating it with a liability attached.
We will tell you when a problem should not be AI. If a deterministic rule or a lookup table solves it, we build that instead. We tell you in the first reply, before any invoice is signed.
The six moves, applied to a model.
Discover. Name the decision the model must support and the cost of a wrong answer. If the cost is low, do not build this.
Design. Choose between retrieval, fine-tuning or tool use before writing prompts, and write the acceptance criteria as a test set.
Build. Retrieval, generation and validation as separate, replaceable components behind one service interface.
Deploy. Ship to a narrow audience with an evaluation harness that runs on every change and every model upgrade.
Learn. Log real queries and failures. The test set grows from your actual traffic, not from our imagination.
Scale. Add capacity, caching and cost controls only after the answer quality holds under real load.
A stack chosen per problem, not by default.
Models are selected for the task and the cost envelope: frontier APIs for work that needs reasoning, smaller hosted models where latency or price dominate, and small open-weight models where data must stay on your infrastructure.
Around them we build retrieval over your own sources with chunking, embedding and reranking tuned for the corpus; tool use and function calling for actions that touch real systems; and structured output validation so a response that fails to parse never reaches a user. Python is the default for the service layer, with TypeScript where the interface sits closer to the user.
Bring one decision, not a vision.
The fastest start is a single workflow where a person currently spends a fixed amount of time per item: reading documents, triaging a queue, writing a first draft, or looking something up across several systems.
Send the workflow, the volume you handle per week and where the answer ends up. We reply with whether it should be AI, what we would build first, and the pieces we would leave as plain software.
More practice areas.
These services share the same stack and the same pipeline, and they usually show up in the same engagement.
Tell us what you are trying to ship. We reply with a scope, a timeline and the tools we would use.
An agent is a loop, not a prompt. It takes an objective, plans a sequence of steps, calls tools, checks the result, and decides what to do next. The value is the loop.
A loop that acts, with an audit trail.
An AI agent is a model wrapped in a control loop: plan, act, observe, revise. It reads context, chooses an action from a defined set of tools, calls real systems, reads the outcome and keeps going until the objective is met or it reports a blocker.
We build agents for work that has steps but no fixed path: researching a question across sources, working through a queue where each item needs different handling, or producing an artefact that has to be verified before it ships. The output is always accompanied by the trace of how it got there.
Autonomy is only worth it when it is bounded.
Unbounded autonomy is not a feature. An agent that can act anywhere will eventually act badly somewhere, and the cost of fixing that is higher than the work it saved.
The design question is where the boundary goes: which actions the agent takes alone, which it proposes for approval, and which it is not allowed to attempt at all. Draw that line explicitly and you get speed with a system you can trust. Draw it implied, and you get an incident.
Every agent we ship logs its full trace: objective, plan, each tool call, each observation and the final decision. You can read exactly what it did and why, and that log is what makes the next version better.
Plan, act, observe, revise.
Discover. Write the objective in one sentence and list the systems the agent may touch. If the objective cannot be written that way, it is not ready for an agent.
Design. Define the tool set, the approval points and the failure modes before any code is written.
Build. A small, explicit state machine over the model, so the agent's behaviour is reviewable rather than emergent.
Deploy. Run in propose-only mode first. Promote actions to autonomous one at a time, as the trace proves them safe.
Learn. Review failed runs. Each one becomes a test case in the regression suite.
Scale. Add concurrency and scheduling once the single-run behaviour is reliable and bounded.
Small tools, explicit contracts.
Agents live on the same foundation as our AI work: LLM orchestration for reasoning, structured output so the plan is machine-readable, and retrieval when the context lives in your own documents. What changes is the control layer.
Tool use is the core interface. We define each tool with a typed contract, an idempotency story and a permission level, then expose only that surface to the agent. Queues and scheduling sit underneath, so an agent run can be retried, paused and resumed without losing state. Everything is captured in a trace you can query after the fact.
Start with the queue you hate.
Pick the workflow where a person starts a task, switches context, and comes back to it three times a day. That repetition is what an agent removes, and it is the shape where a failure is easy to contain.
Send the workflow, the tools it currently needs and the actions that must stay human-approved. We will tell you which parts an agent can own and which ones it should only draft.
More practice areas.
These services share the same stack and the same pipeline, and they usually show up in the same engagement.
Tell us what you are trying to ship. We reply with a scope, a timeline and the tools we would use.
Ordinary automation moves data between systems. AI automation adds a step that requires reading, deciding or writing. That is the step that was always manual.
The step that needed a person.
Most business pipelines already run: forms arrive, data moves, reports generate, notifications fire. The manual step sits inside one of them, and it is the step that looks like reading, classifying, extracting or summarising.
AI automation puts a judgement step in that position. Instead of a person opening every item and deciding where it goes, the system reads it, proposes a decision, executes the safe part and escalates the uncertain part. The queue still empties; the person now only handles the exceptions.
Latency compounds, attention does not.
A manual step inside an automated pipeline has a queue that grows during business hours and empties after them. That delay is not the problem by itself; the problem is that people optimise for the average and the queue optimises for the outlier.
Automating the classification changes the shape of the work: exceptions surface immediately, the common case costs nothing, and the team's attention goes to the items that actually need it. That is a structural improvement, not a speed tweak.
We build the safe path and the escalation path together. Automation without a designed fallback is a spreadsheet with better typography.
Detect, classify, execute, escalate.
Discover. Find the step in your existing pipeline where a person reads and decides. Measure its volume and its cycle time.
Design. Split the work into the routine majority and the ambiguous remainder, and define what triggers an escalation.
Build. Detection, classification and execution as separate stages, each with its own tests and its own failure handling.
Deploy. Run the automation in shadow mode against live volume first, comparing its decisions to what a person would have done.
Learn. Promote decision classes as their accuracy is proven. Keep the rest in review mode.
Scale. Only then remove the human step entirely, for the classes that have earned it.
Reliable pipes, modelled decisions.
The pipeline half is ordinary engineering: event queues, retries with backoff, idempotent handlers and a dead-letter path for anything that fails permanently. The judgement half is a small model call with structured output, wrapped in the same reliability guarantees.
We keep those two halves separate on purpose. When a model is replaced, the pipeline does not change. When a source system adds a field, the model does not change. That separation is what makes these systems boring to run and safe to extend.
Name the queue and its cycle time.
The useful input is a queue you already run: inbound documents, support tickets, leads, approvals, or anything that arrives and needs reading before it moves on.
Send the queue, roughly how many items a week, and how long each one takes. That is enough for us to say whether automation pays for itself and which half of it needs to be AI rather than rules.
More practice areas.
These services share the same stack and the same pipeline, and they usually show up in the same engagement.
Tell us what you are trying to ship. We reply with a scope, a timeline and the tools we would use.
Product & SaaS
Multi-tenant products built to charge and grow, then engineered past v1.
A SaaS product is not a web app that happens to charge. It is a system where ten isolated customers behave differently and none of them can see each other.
Tenancy is the hard part.
SaaS development is the work of building software that serves many customers from one codebase, one deployment and one set of infrastructure, with strict boundaries between them. Every query, every cache key, every notification and every job has to know which customer it belongs to.
We build the whole of it: the data model, multi-tenant access control, authentication and identity, billing and subscription lifecycle, administration surfaces, and the telemetry that tells you how each customer actually uses what you shipped.
Architecture decisions become expensive in month six.
The first version of a SaaS product almost always works. The problems start when the second customer has different permissions, the third needs a different retention policy, and the fourth needs to migrate their own data.
Getting tenancy, billing and identity right early is a small cost now and a large avoidance later. Retrofitting them onto a product with real usage means reworking every screen and every migration, in front of paying customers who can feel it.
Nothing ships without a tenant boundary test. Every access path is exercised as customer A and customer B, and both must fail closed. That is a feature we will not waive, on a timeline or a budget.
From a validated problem to a paying tenant.
Discover. State the problem in one sentence and name the first customer you would build for. If you cannot name one, the product is not ready.
Design. Fix the tenancy model, the permission model and the billing unit before the first screen is drawn.
Build. One vertical slice end to end: authentication, one workflow, billing, notifications. Shipped and used.
Deploy. Production infrastructure from day one. Staging environments are for people who do not have customers yet.
Learn. Measure activation and the actions that lead to retention. Optimise the funnel you actually have.
Scale. Add the second and third use case only after the first holds under real load and real support load.
Standard choices, applied with care.
We default to a boring stack on purpose: TypeScript and a modern framework for the interface, Node or Python services behind it, PostgreSQL with row-level tenancy enforced at the database, and a managed deployment platform with preview environments for every change.
Billing and subscriptions run on established processors rather than a bespoke implementation, with the lifecycle events handled by our code. Authentication is delegated to an identity provider. The engineering effort goes into the parts that are specific to your product, which is where the value actually lives.
Start with the workflow, not the platform.
The most useful first message names the workflow your future customer repeats and the outcome they are paying for. Platform features follow from that; starting from platform features produces tools nobody keeps using.
Tell us the workflow, the customer and what they do today instead. We will tell you whether that becomes a SaaS product, an internal tool, or an automation, and what the smallest real version looks like.
More practice areas.
These services share the same stack and the same pipeline, and they usually show up in the same engagement.
Tell us what you are trying to ship. We reply with a scope, a timeline and the tools we would use.
Custom software is any system that does not yet exist and that fits your process because someone decided it should. We build those systems end to end.
One team, one accountable stack.
Software development is the work of turning a constraint into a system that removes it. That includes the interface a person uses, the service that does the work, the data model that holds it, the integrations that connect it to the tools you already run, and the infrastructure that keeps it running.
We do not split these across vendors. The person who designs the data model writes the interface on top of it, and the person who writes the integration owns the failure mode when it breaks. Fewer handovers is a feature, not a staffing detail.
Handovers are where projects die.
The most common cause of a failed software project is not a bad idea. It is a sequence of handoffs: requirements to design, design to build, build to operations, operations to whoever answers the pager.
Each handoff loses information, and the information lost is usually the unspoken part: what happens when the input is wrong, what the edge case was, why the field has that shape. Keeping the work with one team means those decisions stay attached to the code that implements them.
Every increment ships with tests and a rollback path. We would rather deliver a small working piece you can run today than a large plan you can read tomorrow.
Six moves, one pipeline.
Discover. Name the constraint blocking the work and who is affected by it. Write the constraint, not the feature.
Design. Structure, interface and system decided before a line is written. The spec is signed off, then it stops changing casually.
Build. Working software in small, verifiable increments. Each one is testable and, if it is wrong, reversible.
Deploy. Ship early into a real environment, measure everything, and roll back fast. Deploying is a routine act, not a milestone.
Learn. Real usage decides the next increment. We do not extend a plan based on assumptions about it.
Scale. Automate the repeatable parts and add capacity where the load is real, not where it is imagined.
Chosen for the problem, not for the resume.
The default is a small set of well-understood tools: TypeScript for interfaces, Python or Node.js for services, PostgreSQL for data, and a managed deployment platform with preview environments. Where the work needs something else, we say so and explain why.
We favour boring technology for the reasons people expect: fewer incidents, easier hiring later, and no hidden migration cost. The interesting parts of a project are the domain logic and the integrations, so that is where the unusual choices go.
Describe the constraint.
The fastest start is the thing that is slowing you down today: a process that takes longer than it should, data that lives in three places, or a decision that needs a report to be assembled by hand.
Send the constraint, who it affects and what you do today to work around it. We will reply with the smallest system that removes it and what we would leave as a manual step for now.
More practice areas.
These services share the same stack and the same pipeline, and they usually show up in the same engagement.
Tell us what you are trying to ship. We reply with a scope, a timeline and the tools we would use.
A one-off build ends at delivery. Product engineering continues: the system keeps changing, and someone has to decide what changes next.
Scope, architecture, build, measure.
Product engineering is the part of building software that happens after the first version ships and continues while it does. It is the work of deciding what to add, what to remove and what to stop supporting, based on what real users do rather than what was originally specified.
We take that responsibility on. That means owning the roadmap, the architecture decisions that constrain it, the release cadence, the quality bar, and the measurement that tells you whether any of it is working.
Shipping is the start of the problem.
The first release answers one question: is there a need? Everything after it answers a different one: which of the things you built does anyone rely on?
Without that answer, a product accumulates. Features are added because they were requested, and nothing is removed because it was requested too. The codebase gets slower, the interface harder to learn, and the team more defensive about changing anything. Product engineering is the discipline that keeps the opposite from happening.
We will recommend removing features. A product that has never been subtracted from is not a product, it is a warehouse.
Decisions, then the code that follows.
Scope. Write down what the product does, for whom, and what it deliberately does not do. That document constrains everything later.
Architect. Set the boundaries the team will live inside: tenancy, permissions, integrations, data ownership. Changing these later is expensive.
Build. Release small, verifiable increments on a fixed cadence. Each one earns the next through evidence.
Measure. Instrument the actions that matter before they are built, so the next decision is based on a number rather than a feeling.
Iterate. Add what is proven, remove what is not, and revisit the scope document when the evidence changes.
Maintain. Carry the debt deliberately: log it, size it, and pay it in scheduled increments rather than in an emergency.
A stack you can hand over.
We build on the same standard choices as the rest of our work, because a product that has to be maintained for years needs to be readable by people who were not involved in writing it. TypeScript and a modern framework for the interface, Python or Node.js for the service layer, PostgreSQL for the data.
Alongside the code, product engineering produces the operational side: a release process, a monitoring setup that pages on something real, a backlog sorted by evidence, and documentation written for a future maintainer rather than for today's debugging session.
Bring the product, not the idea.
Product engineering works best on something that exists and has users, or on an idea with a specific first customer in mind. Either way, we need to know what the current state is: what is built, what is used, and what is broken.
Send what you have, what the users do with it, and the decision you cannot make because the data is not there. We will tell you what we would build next and what we would stop supporting.
More practice areas.
These services share the same stack and the same pipeline, and they usually show up in the same engagement.
Tell us what you are trying to ship. We reply with a scope, a timeline and the tools we would use.
Web & Interface
Design-system interfaces, web applications, and the integrations behind them.
This site is our reference for the work. Motion, interaction and performance are product features here, not decoration added at the end.
Interactive products, not pages.
Web development here means two things: sites that are designed as systems and applications that behave like products. The first needs an information architecture, a visual system and motion that supports reading rather than interrupting it. The second needs state management, data fetching and error handling that a user can recover from.
Both are built from a design system on purpose: one type scale, one spacing system, one set of components, one set of interaction patterns. That is what makes a large interface feel like one product instead of a series of screens.
Perception is measured in milliseconds.
A slow interface is a worse interface, and the difference is measurable. Layout shifts make people miss clicks, long main-thread work makes scrolling stutter, and both of those show up as abandonment before anyone complains.
Design systems matter for the same reason, on a longer timescale. Without one, every new screen is a new decision, and each decision is a chance for the product to drift. With one, a feature can be built quickly without being allowed to look unlike the rest.
Core Web Vitals are a release criterion for us, not a target we work towards. If a change breaks them, it does not ship. Same for WCAG 2.1 AA on keyboard and screen reader paths.
Design system first, screens second.
Structure. Information architecture and interaction patterns before visuals. Where the user looks is decided before they can look.
System. Tokens, type, colour and components defined once, then used everywhere. Motion is designed as part of this, not layered on top.
Build. Accessible markup and real components. Keyboard and screen reader paths are tested, not assumed.
Optimise. Measure against real devices and real connections. We budget bytes and main-thread time, and we defend both.
Ship. Preview environments for every change, so a screen can be reviewed in the state it will actually ship.
Maintain. Extend the system instead of forking it. A component that needs two variants usually needs a different component.
The stack, in order of importance.
TypeScript is the default, with a component library built around design tokens so that colour, type and spacing live in one place. Motion is handled with GSAP and the Web Animations API, with SVG and canvas where the interface needs something a DOM element cannot do.
Performance is treated as an architecture concern: images sized and loaded for the viewport, JavaScript split by route, critical CSS inlined, and third-party scripts accounted for. Every one of those is a decision that has to be made early or paid for later.
Tell us what the site has to do.
The useful input is the job the site has to do: what a visitor is deciding, what they are looking for, and where they go afterwards. Aesthetic preferences come after that, not instead of it.
Send the purpose, the audience and one site you think does this job well. We will reply with a structure, the design approach and what it will take.
More practice areas.
These services share the same stack and the same pipeline, and they usually show up in the same engagement.
Tell us what you are trying to ship. We reply with a scope, a timeline and the tools we would use.
An integration is not a call. It is a contract between two systems that change independently of each other, and it will break.
Contracts, not calls.
API integration is the work of making two systems talk reliably over time. That means a typed client, a defined response model, handling for every failure mode a provider can return, and a way to notice when the provider changes something you did not ask for.
We build integrations for the tools a business actually depends on: payments, identity, storage, communications, CRMs and internal systems that predate any of them. The deliverable is a piece of infrastructure with a documented contract, not a script that works on the day it is written.
The failure is always on your side.
Third-party systems change. Rate limits move, schemas gain fields, endpoints deprecate, and a provider that returns an error shape you did not test will look exactly like your own bug until someone spends an afternoon figuring out otherwise.
The cost is asymmetric: the provider ships a change on their schedule, and you find out on yours, usually when a workflow stops completing. Integrations built as throwaway glue absorb that cost silently. Integrations built as contracted infrastructure absorb it once, visibly, and get fixed.
Every integration we ship has a contract test against a recorded response, a retry policy with a dead-letter path, and an alert that fires before a workflow stops completing. If one of those is missing, the integration is not done.
Contract, client, resilience, monitoring.
Inventory. List the systems that have to talk, what data moves between them, and what happens today when that movement fails.
Contract. Define the shape of every request and response explicitly, including the error cases and the cases where nothing happens.
Client. Build a typed client with versioning, so the rest of the codebase never sees a raw provider response.
Resilience. Retries with backoff, idempotency keys, circuit breakers and a dead-letter path for anything that fails permanently.
Monitor. Alert on integration failures, not just application errors. A silent failure is the expensive one.
Maintain. Track provider changelogs and deprecations as part of the work, before they become incidents.
Small clients, loud failures.
Each provider gets a thin typed wrapper: one module, explicit schemas, no business logic inside it. Business logic stays where it belongs, and when a provider changes its response the change is contained to a single file.
Underneath sit the reliability primitives: idempotency keys for anything that writes, retries with jittered backoff for transient failures, circuit breakers so a slow provider cannot consume your own capacity, and a dead-letter queue so a permanent failure is visible rather than dropped. Queues and scheduling make the same call retryable across restarts.
List the systems and the data that moves.
The fastest start is a list: which systems have to exchange what, how often it happens, and what goes wrong when it fails. A rough count of calls per day is useful; it decides whether polling or webhooks is the right shape.
Send the systems, the data flows and one thing that has broken in the past year. We will reply with the integration shape and what we would build first.
More practice areas.
These services share the same stack and the same pipeline, and they usually show up in the same engagement.
Tell us what you are trying to ship. We reply with a scope, a timeline and the tools we would use.
Systems & Automation
Work that runs without a person — with the failure path designed first.
Automation only counts if the whole workflow completes. Half of the work is the steps; the other half is what happens when one of them does not.
The whole workflow, or not at all.
Workflow automation is the removal of a sequence of steps that repeat in the same shape: an order placed, a document received, a lead entered, a report due. Each step triggers the next, data moves between systems, and the result is something a person can rely on without checking it.
The system we build has three parts: the trigger that starts it, the state machine that keeps track of where each item is, and the failure handling that decides what happens when a step does not complete. Most automation projects build the first and imagine the third.
Manual steps are the ones that get skipped.
A workflow with a manual step has a queue. Queues build during the day and are cleared when someone remembers, which means the work is done late and inconsistently and the person doing it is interrupted by it all week.
Removing the manual step changes the shape of the work rather than its speed. Exceptions become visible immediately instead of accumulating, and the team's attention goes to the items that need judgement. That is the part automation earns.
We design the failure path before the happy path. A workflow that silently stops at step four and looks complete is worse than the spreadsheet it replaced.
Trigger, track, act, alert.
Map. Write down every step in the workflow as it actually runs, including the ones done by email and by memory.
Decide. Choose the trigger for each step: an event, a schedule, or a manual approval. Manual approvals stay manual by design, not by accident.
Build. Each step as an idempotent handler with its own tests, joined by a state machine that records where every item is.
Fail safely. Retry what is transient, park what is permanent in a dead-letter path, and alert on anything that has been stuck longer than it should.
Observe. Expose workflow state to the people who run the business, so a stuck item is visible without opening code.
Extend. Add steps against the same contracts. New branches should not require reworking the ones already running.
Queues and schedules, nothing cleverer.
The building blocks are unglamorous and dependable: message queues for anything triggered by an event, schedulers for anything on a clock, a state store that records each item's progress, and handlers that are safe to run twice.
Everything is wrapped in observability: each workflow has its own counters, ages and error rates, so a stuck queue is detected in minutes and not discovered by a customer. Alerting is configured against what the business notices, not what the system logs.
Describe one workflow as it actually runs.
Pick the workflow you would write out on a whiteboard in ten minutes: how it starts, every step, and where a person currently touches it. Include the steps that happen by email or in someone's head; those are usually the ones worth automating.
Send the steps, roughly how many times a week it runs, and where the finished result has to end up. We will reply with which steps should be automatic, which should stay as approvals, and what breaks first if we get it wrong.
More practice areas.
These services share the same stack and the same pipeline, and they usually show up in the same engagement.
Tell us what you are trying to ship. We reply with a scope, a timeline and the tools we would use.