System we operate
Daena
A multi-tenant Python and FastAPI platform with a React front end, in beta.
Beta, with access on request at daena.mas-ai.co. It is the reference architecture we draw on for governed agent builds.
Read the case study
Custom software, built around how you work
When a product on the shelf almost fits, the gap costs you every day. We build the web app, internal tool or API that fits your process, and connect it to the systems around it.
When custom software is the right answer
“We run the business on spreadsheets and they are breaking.”
An internal tool with the same logic, proper access control, a history of changes and reports that come from live data.
“No product on the market does exactly this.”
We build the specific thing and only the specific thing, so you do not pay for a platform you will not use.
“Our systems do not talk to each other.”
An integration layer of APIs and scheduled sync, with checks that flag records that do not match.
“We want AI in our product but do not know where it belongs.”
We add it at the points where it removes work, behind an interface your users already understand, with evaluation so you can see that it works.
“We are launching a product and need it engineered, not prototyped.”
Product engineering from data model to deployment. Multi-tenant if you need it, tested, and deployable by your own team.
What we build
Six kinds of work, from a single internal tool to a full product.
Custom web applications
Applications your customers or staff use in the browser: accounts, roles, workflows and payments where they are needed.
Internal tools and dashboards
Replace the spreadsheet with forms, approvals, reports and dashboards over your live data.
SaaS and product engineering
From data model to launch: multi-tenant architecture, billing hooks, admin, monitoring and the deploy pipeline.
Python and FastAPI APIs
Backends and APIs, asynchronous where it helps, typed and documented so other systems can rely on them.
AI inside existing software
Search, drafting, classification or an assistant added to a product you already run, with evaluation and a fallback for when the model is unsure.
Integration layers
Connectors and sync jobs between your CRM, accounting, inbox and database, with retries and mismatch alerts.
What you receive
- Source code in a repository you own, with the commit history.
- Automated tests and a written description of what they cover.
- Deployment scripts and environment setup, so a new environment can be created from the repository.
- Architecture notes: what each part does and why it was built that way.
- A runbook for running, monitoring and updating the system.
- A handover walkthrough for your team or your next developer.
Does it connect to what we already use?
Yes. Nearly every custom system we build sits beside existing ones, so integration is part of the design from the first week.
- Your database
- CRM
- Accounting
- Email and calendar
- Single sign-on
- Payment providers
- Third-party APIs
- Webhooks
- File exports from legacy systems
Where a system exposes only exports or a screen and no API, we say what that costs in reliability before we build on it.
Where it can run
Most software can run anywhere. What changes is who operates it and how it scales.
On your devices
Fits, with limits
Desktop or local-first tools for one user or one office. Multi-user software with shared data needs a server.
On your servers
Fits
On your servers or virtual machines, packaged in containers and documented for your IT team.
Private cloud
Fits
In your own cloud account, so billing, access and data residency stay yours.
Hybrid
Fits
Core system in one place and specific services in another, for example a local database with a cloud email service.
Cloud
Fits
The default for most products: managed hosting, quick to scale, standard monitoring.
How it is built
For technical readers: what we choose from. The choice is made per system, from your data, your constraints and your workload.
- Applications
- Web apps, portals, internal tools and APIs in TypeScript and Python, with React, Next.js and FastAPI.
- Data
- Postgres, SQLite and the databases you already run, with vector search where retrieval needs it.
- Access
- Sign-on through your identity provider, roles and permissions, and audit logs.
- Hosting
- AWS, Microsoft Azure or Google Cloud, or your own servers, with the infrastructure written as code where your setup allows.
- Quality
- Automated tests, type checks and release checks before anything ships.
Software we build and run ourselves
We do not publish client work. These are products we built and operate, at different stages of maturity.
MCP Switchboard
A TypeScript product released as open source: dashboard, command line, encrypted vault and audit log.
Open sourceRead the case studyKYA Mission Control
Research stage: signed receipts, an offline verifier and an interactive demo, in Python and TypeScript.
R&DRead the case study
Questions we get
Should we buy software or build it?
Buy when a product covers most of the process and you can live with the rest. Build when the process is your advantage, when no product fits, or when the glue between products costs more than the software would. We tell you which it is, including when the answer is to buy.
Do we own the code?
Yes. The code, the data and the accounts are yours, as set out in the contract. The handover includes documentation so another developer can take it on.
What technology do you use?
Python and FastAPI for backends, TypeScript and React for front ends, SQL databases and containers for deployment. Where you already have a stack, we follow it.
Can you work with our existing developers?
Yes. We work in your repository, follow your conventions and hand over in a form your team can maintain. If you have no developers, we write it so the next person you hire can maintain it.
How do you keep scope under control?
We agree a scope in writing before the build. A change is priced before it is made, so the price does not drift quietly.
Can you add AI to software we already run?
Yes. We add it where it removes work, keep it behind the interface your users know, and test its output against real examples. If it is not accurate enough for the job, we tell you and do not ship it.
Bring us the software you cannot buy.
We start with the problem, then tell you whether it is worth building.
Bring us a bottleneck