- Problem
- A support team reads and routes several hundred inbound emails a week by hand.
- Product
- A system that reads each message, routes it, and drafts a reply for a human to approve.
- Outcome
- The queue triages itself. People spend their day on the messages that need judgement.
What we havebuilt and run.
Most of what we build belongs to the company we built it for, and their name is not ours to publish. So this page has two things on it: a full platform this team designed, built and ran end to end, and examples of the shape a project takes.
A multi-tenant AI SaaSplatform, end to end.
It was built for our own account rather than a client's, which is the only reason we can describe every layer of it here.
Product
A multi-tenant AI conversation platform: an embeddable assistant, a tenant admin portal, an operator console, a marketing site and a mobile app.
AI
Retrieval over each customer’s own content with vector search, grounded answers, source attribution, answer-quality tracking and content-gap detection.
Backend
A FastAPI service with per-tenant data isolation, role-based access, background workers, scheduled crawls, webhooks and a documented API.
Commercial
Plans, feature gating, usage metering, overage handling, trials and upgrade flows. Most teams build this later than they should have.
Integrations
Shopify, WooCommerce, Slack, Jira, Linear and generic webhooks, with idempotent event handling and retry-safe delivery.
Infrastructure
Deployed, monitored and operated by us: environments, migrations, backups, rate limiting, incident response and on-call.
Problem → Product→ Outcome.
- Problem
- Infrastructure changes get approved in chat threads, with no record of who approved what.
- Product
- An internal approval platform with request templates, reviewers, policy checks and an audit trail.
- Outcome
- Every change has an owner, an approver and a history. The process stops depending on who is online.
- Problem
- A service business delivers the same work by hand for every client and cannot grow past its headcount.
- Product
- A multi-tenant SaaS product: accounts, roles, billing, customer dashboards and an internal admin.
- Outcome
- The service becomes a product that can take a new customer without adding a person.
- Problem
- Every production incident gets investigated from scratch by whoever happens to be awake.
- Product
- An incident assistant that pulls logs, metrics, recent deploys and prior incidents into one timeline, with a first hypothesis.
- Outcome
- Investigation starts from context instead of a blank page, and the knowledge stops leaving with people.
- Problem
- Two systems are kept in sync by someone copying data between them every morning.
- Product
- An event-driven integration with idempotent sync, reconciliation, and alerts when the two sides disagree.
- Outcome
- The morning job disappears. A broken sync becomes an alert instead of a discovery.
- Problem
- A company has years of documents and no reliable way to answer questions from them.
- Product
- Retrieval over their own content, with source attribution, access control and answer-quality tracking.
- Outcome
- People get answers with a source they can check, and the questions nobody can answer become a visible gap.
Why there are nologos on this page.
Much of what we build is internal software, or a product our client would rather introduce to the market themselves. Publishing a client list would be easy. It would also be the first promise we broke.
Over email we can go through relevant work in detail, and where a client has agreed to it, introduce you directly. Ask. It is a fair question.
What wouldyours look like?
Describe the problem and we’ll sketch the product back: scope, shape, and a first version you could put in front of users.
