What we do
Software, applied AI, and the ventures that come out of them
Three practice areas run by one team. Each is a real line of work with its own standards — and each is stronger for sitting next to the other two.
Practice 01
Software development
We design, build and operate production software. Not prototypes handed over at the door — systems that other people depend on, with the operational work that implies.
A typical build starts with the workflow that has to change and the constraints around it: who touches the data, what has to be provable afterwards, where the load actually falls. From there we design the smallest architecture that answers those constraints honestly, then ship it in increments that can go live rather than in one long push towards a launch date.
We work in typed codebases with automated tests and reproducible deployments, because the alternative gets expensive at exactly the moment a product starts to matter. Security is treated as part of the design rather than a review at the end: least-privilege access, encryption in transit and at rest, scoped permissions, and audit trails wherever an action needs to be accounted for later.
Capabilities
- Product architecture and technical due diligence
- Web applications, APIs and background processing
- Mobile applications and their release pipelines
- Data platforms, ingestion and reporting
- Cloud infrastructure, CI/CD and observability
- Security review, access control and audit logging
Practice 02
Applied AI
We put machine learning inside products where it changes the result, and we hold it to a measurable standard before it goes anywhere near a user.
The interesting work is rarely the model. It is the pipeline around it: getting messy source documents into a structure worth reasoning over, retrieving the right context, constraining the output so it can be checked, and presenting the result with its evidence attached so a professional can accept or reject it in seconds.
Every AI feature we ship carries an evaluation harness — a fixed set of cases with known answers, run on every change, so quality is a number rather than an impression. We state what a system cannot do as plainly as what it can, and we design the interface so the human stays in the position to decide.
Capabilities
- Document extraction and normalisation from unstructured sources
- Retrieval-augmented analysis over private domain data
- Risk scoring, anomaly detection and exception surfacing
- Evaluation harnesses, regression suites and quality metrics
- Guardrails, cost control and prompt/version management
- Human-in-the-loop review interfaces with evidence trails
Practice 03
Venture investment
We invest our own capital in early-stage companies we build with or alongside, and we back that money with engineering.
Bidfins is an operator first. When we invest, it is usually in something we have helped design, staff or de-risk technically, and we stay involved afterwards — architecture, hiring, security posture, the unglamorous parts of getting a product into a regulated market.
That means we are slow, concentrated and long-term by design. We are not a fund, we do not take outside money, and we do not run a process. If there is a fit, it normally starts with a build.
Capabilities
- Own-balance-sheet investment in early-stage ventures
- Founding, co-founding and operating roles
- Technical diligence for our own positions
- Architecture and engineering support post-investment
- Hiring and team design for early technical teams
- Long holding periods, no external mandate to satisfy
A note on our investment activity
Bidfins Limited invests its own capital in the ventures it builds. It does not provide financial services or investment advice, does not manage money on behalf of others, and does not solicit investment from the public. Nothing on this site is an offer of securities or a financial promotion.
Have a build in mind?
Send us the problem in a paragraph or two — the workflow that has to change, the constraints you are working inside, and the deadline you are working towards.