What we do
Four things, done properly
Each of these includes what it is for, what you receive, and when you should not hire us for it. If a cheaper or simpler answer exists, we would rather tell you than sell around it.
Start from the problem
Not sure which of these you need?
Most people arrive describing a solution they have already picked. It is usually more productive to start from the problem. Find yours below.
“The same data gets typed into three systems every day.”
Workflow automation between the tools you already run.
“Everyone has ChatGPT. Nothing about how we work has changed.”
AI productivity — redesigning the recurring work around the tools.
“Invoices and forms are processed by hand, one at a time.”
Document processing into structured, validated data.
“Nobody can find anything. The answer exists somewhere.”
An internal knowledge assistant that cites its sources.
“Our system works but it is old, slow and nobody wants to touch it.”
Modernisation — make what you have work properly.
“We have a product idea and need it built.”
Product engineering, from architecture to launch.
“Our product works but users keep failing at the same step.”
Product design grounded in the real workflow.
“We tried an AI pilot and it never reached production.”
The gap between demo and production is the work we do.
Web, Mobile & SaaS Product Engineering
Websites, web applications, mobile apps and cloud-native SaaS platforms — taken from architecture through deployment and the maintenance that follows. Most of this work is either a first product that has to reach real users, or an existing one that has outgrown how it was originally built. Native-quality mobile on iOS and Android via React Native and Flutter; web on Next.js and React. Everything is documented and tested so it can be maintained by someone who did not write it — including your own team, if you take it in-house later.
Who it’s for: Founders with a product to get built, and teams whose existing product has outgrown how it was first written.
What you can build
- Customer-facing web applications and marketing sites
- Mobile apps for iOS and Android from one codebase
- Multi-tenant SaaS platforms with billing and roles
- Internal tools that replace a spreadsheet nobody trusts
- APIs and integrations between systems that don't talk
What you receive
- Working software in a real environment, not a demo
- Documented architecture with the trade-offs written down
- Test coverage on the parts that would hurt if they broke
- Deployment pipeline and monitoring you own
- A handover another engineer could pick up
Use this when
You need something built properly the first time, or an existing product has become slow, fragile or impossible to change safely.
Don’t use this when
An off-the-shelf product already does this. If Shopify, Airtable or a vertical SaaS covers 80% of your need, custom software is usually the expensive answer — and we will say so.
How it runs
- 1Scope locked and priced
- 2Architecture decided and documented
- 3Two-week build cycles
- 4Tested on real data
- 5Deployed with monitoring
- 6Handover and support window
AI Integrations & Workflow Automation
Practical AI and automation work: connecting the tools you already pay for, processing your real data, and taking repetitive work off people's desks. This is where most AI projects stall — a demo works on clean sample data, then meets legacy systems, expired credentials, inconsistent records and edge cases nobody documented. We build for that second part. We will also tell you when a problem does not need AI at all: a scheduled job or a straightforward integration is often cheaper, faster and far more reliable than a model.
Who it’s for: Operationally busy businesses where information moves by hand, and teams whose AI pilot worked in a demo and then stalled.
What you can build
- Workflow automation between disconnected systems
- Document processing — invoices, forms, contracts into structured data
- Internal knowledge assistants that answer from your documents and cite sources
- LLM features inside an existing product
- AI agents where they genuinely fit
- Reporting that assembles itself
What you receive
- The workflow running in production, not a prototype
- Error handling, alerting and a fallback when the model or API fails
- Human review built into anything consequential
- Documentation of what it does and what it deliberately does not
- A measurement of the manual time it actually removed
Use this when
The same task is done repeatedly by a person, the inputs are messy or unstructured, or a previous AI attempt never made it past the demo.
Don’t use this when
The process is undefined, or the volume is low. Automating a broken process makes it fail faster. And plenty of problems are better solved by a scheduled job, a proper integration or a $30/month tool than by a model — we will tell you when that is the case.
How it runs
- 1Map the process as it actually runs
- 2Quantify the time it costs
- 3Decide AI, automation, or neither
- 4Build and test on real data
- 5Parallel run against the manual process
- 6Cut over, monitor, hand over
Product Design & UI/UX
Design that starts from what the product has to do. We map the real workflow first — who uses it, how often, and what they are trying to finish — then design the interface around that. The output is a working design system your developers can build from, not a set of screens that look good in isolation and fall apart on the third state nobody drew. Accessibility is treated as a build requirement, not a later audit.
Who it’s for: Teams building something new who want the workflow right before it is expensive to change, and products that have grown inconsistent.
What you can build
- Design systems and component libraries developers build from
- End-to-end product flows, including the states nobody draws
- Responsive web and mobile interfaces
- Prototypes for testing a flow before committing to it
- Accessibility built in from the start
What you receive
- A component library your developers can implement directly
- Designs covering empty, loading, error and permission states
- Research findings with the reasoning behind each decision
- Accessibility considered at design time, not audited afterwards
Use this when
You are building something new, your product has become inconsistent as it grew, or users keep failing at the same step.
Don’t use this when
You want a visual refresh with no underlying problem to solve. That is branding work, and a design studio will serve you better than we will.
How it runs
- 1Understand the real workflow
- 2Map the flow end to end
- 3Prototype the risky parts
- 4Test with real users
- 5Build the system
- 6Hand to engineering
Growth & Digital Marketing
Engineering-led growth for products that are built but not found. Technical SEO, analytics instrumentation that measures something worth acting on, and conversion work grounded in what the data actually shows. This is the smallest of our four services and we are candid about that: if you need a full marketing department, you need an agency, not us. If you need the technical side done properly and measured honestly, that we can do.
Who it’s for: Teams with a product that works and an audience that cannot find it, where the bottleneck is technical rather than creative.
What you can build
- Technical SEO — metadata, structured data, architecture, Core Web Vitals
- Analytics and conversion tracking worth acting on
- Landing pages and funnels measured properly
- Content structured for search engines and AI assistants
What you receive
- A technical SEO baseline and what it changed
- Analytics measuring decisions rather than vanity metrics
- Documented recommendations you can act on without us
Use this when
Your product is sound but invisible, your analytics do not answer real questions, or search traffic is not converting.
Don’t use this when
You need a full marketing department, brand campaigns or paid media at scale. That is an agency's job, not ours — this is the smallest of our four services and we would rather say so than oversell it.
How it runs
- 1Audit what is measurable today
- 2Fix the technical foundation
- 3Instrument the funnel
- 4Measure
- 5Recommend
- 6Hand over
Tools
What we build with, and why that is the least interesting question
Tools change faster than problems do. We pick per project based on your constraints — what your team can maintain, what your data policy allows, what you already run — rather than defaulting to whatever we used last time. This is what we reach for most often, not a list of everything we have touched.
Product engineering
Next.jsReactTypeScriptNode.jsPythonChosen for maintainability and hiring pool as much as performance — you should be able to find someone else who can work on it.
Mobile
React NativeFlutteriOSAndroidCross-platform by default. Native only where a platform capability genuinely requires it.
AI and automation
OpenAIClaudeOpen-source modelsRAG pipelinesWorkflow automation platformsDeliberately not committed to one provider. Model choice follows the data policy and the task, and sometimes the answer is no model at all.
Data and infrastructure
PostgreSQLAWSGCPVercelCI/CD pipelinesWe favour boring, well-understood infrastructure. Interesting infrastructure is a liability at 3am.
Design
FigmaStorybookTailwind CSSDesign systemsDesign output that developers can build from directly, rather than pictures to reinterpret.
Measurement
Analytics instrumentationConversion trackingTechnical SEO toolingInstrumented to answer specific questions. Dashboards nobody opens are not measurement.
Working together
How we work with clients remotely
Most of our clients are in other countries and time zones. Distributed work only fails when nobody designs for it, so here is exactly how an engagement runs.
One person owns your project
You work with the same senior person from first call through handover. No account manager relaying messages to an unnamed team.
Written by default
Decisions, scope and trade-offs go in writing. You should never have to attend a meeting to find out where something stands.
Overlap hours, agreed upfront
We commit to a window that overlaps your working day and hold it. Outside it, you get async updates rather than silence.
Fixed scope and written change process
The scope, price and exclusions are agreed before work starts. Changes are quoted and approved, not absorbed quietly and repaid in delays.
Working software every two weeks
Progress you can open and use in a real environment — the only honest status report.
Handover, not lock-in
Documentation, credentials and code are yours. If you take it in-house or to another team, that should be straightforward.
How we work
How an engagement actually runs.
Four stages, and the first one matters most. Working out what not to build is usually worth more than building faster — so we spend real time there before anything is committed to code.
Discovery and scoping
We map the process or product as it works today — systems, data, the people involved, and where it breaks. Most of the value is here: knowing what not to build is usually worth more than building faster.
Architecture and trade-offs
We choose an approach and write down why, including what we ruled out. You see the trade-offs — cost against flexibility, speed against durability — before anything is committed to code.
Build in two-week cycles
Working software at the end of each cycle, in a real environment you can use. Scope is fixed, and changes are priced and agreed rather than absorbed silently and paid for in delays.
Production and handover
Tested against real data and real edge cases, not a clean demo set. You get documentation, monitoring and a handover written so another engineer could pick it up — including one who doesn't work for us.
Still not sure?
Describe the problem rather than the solution and we’ll tell you honestly which of these fits — including if the answer is none of them. See what things cost first if that is useful.
Describe your problem