Logo for Si Novi, a UK-based software consultancy Logo for Si Novi, a UK-based software consultancy

The APIs your product and your business depend on

Whether an API is the product you sell or the plumbing that keeps your operation moving, it needs to be fast and secure, and safe for your team to change.
The problem

Most API trouble starts long before anyone writes any code.

You feel it in small ways first. A mobile release waits because the endpoint it needs does not exist yet. A report takes a fortnight because the numbers live in three systems that have never spoken to each other. An integration with somebody else's API is fine right up until their outage becomes your Monday morning.

None of that is really an API problem. It is a design problem that surfaced as one, and it is much cheaper to fix at the specification stage than after a hundred clients are depending on the shape of your responses.

When the API is the product

In SaaS platform development the API is often the thing customers actually buy. It is what their developers integrate with, what your mobile app talks to, and what your pricing gets built on. It has to be documented, versioned and stable enough that changing it does not break somebody else's business.

When the API runs the business

In business operations software the API is connective tissue. It is what lets a quoting tool, a survey app and a finance package behave like one company rather than four spreadsheets and a lot of copying and pasting.

How we work

We work out what the API has to do before we decide what it looks like.

  1. 01

    Specify

    We sit down with the people who will use the thing and map what has to happen, using event storming and story mapping. The endpoints fall out of that. Designing them first, and finding the workflow afterwards, is how you end up with an API shaped like your database instead of your business.

  2. 02

    Build

    REST where it fits, GraphQL where the client genuinely needs to choose its own shape of data. Versioned from the first release rather than the first breaking change. Documented as we go, so the developers who consume it are not reading your source code to work out what a 422 means.

  3. 03

    Run

    We stay. Someone has to watch the error rates, keep the dependencies current and answer the phone when a consumer of your API starts behaving oddly. In most of our engagements that is still us, years after launch.

What's included

What you get, from first sketch to running service.

  1. 01

    Design and specification

    We start from the workflow, not the schema. Event storming and story mapping with the people who will use it, then a resource model and an endpoint design that follows. You get the specification before we build against it, and you get to argue with it.

  2. 02

    Security and access control

    Authentication, authorisation on every request, validation of anything a client sends, and encryption in transit and at rest. Security is part of the design, not a hardening pass at the end. Where it fits we use Cognito rather than rolling our own.

  3. 03

    Performance, caching and cost

    Serverless APIs on Lambda and API Gateway scale with demand and cost nothing when idle. CloudFront caches what can be cached. We measure before we optimise, and we tell you when a change would buy speed you do not need.

  4. 04

    Documentation and versioning

    An OpenAPI description generated from the API rather than maintained alongside it, so it cannot drift. Versioning from day one, so the release that adds a field does not break the client written last year.

  5. 05

    Consuming APIs you do not own

    Plenty of our work is on the other side of the request: pulling data out of somebody else's system, in JSON, XML or whatever they hand back. The interesting part is what happens when they are slow, rate-limited or down, and how much of that your users should ever see.

“Si Novi have played a crucial role in the development of Culture Segments TagTool, from its inception to what it is today. They have brought to life our vision for the product with a thoughtful and creative approach.”
Elinor James, Chief Executive, Morris Hargreaves McIntyre

Work that runs on the APIs we built

The stack is usually Node.js or PHP behind AWS Lambda and API Gateway, with CloudFront in front and Cognito handling identity. We are an AWS Select Tier Services Partner and we run a Well-Architected review on every engagement, which is a large part of why the bill does not surprise anyone in month four.

Read the Cloud Excellence Framework
Questions

The things buyers ask us first.

  • Will we be locked in?

    No. Everything we build runs in your own AWS account, and you get a copy of all of it, including the infrastructure definitions and the deployment pipeline. You can take it elsewhere whenever you want. An engagement that only survives because leaving is painful is not one we want.

  • Can you work with the API we already have?

    Usually, yes. We will read it, tell you honestly what state it is in, and give you the options. Sometimes that is a rewrite. More often it is a versioned path forward.

  • Does it have to be on AWS?

    No, though it usually is. We know AWS deeply enough to make it cheap and boring, and that is worth more to you than a stack we would be learning at your expense.

  • Who will actually build it?

    The two founders, and the trusted collaborators we bring in around them. No account manager between you and the people writing the code, and no junior learning on your project.

Related

An API rarely arrives on its own.

Work we have done for businesses like yours

Golf course
Insurance platform rebuild Published 2026

Rubber Ring

Rubber Ring's digital insurance business had outgrown its original platform.

Discover how we rebuilt it on a modern, event-sourced architecture on AWS - a single-table DynamoDB source of truth streamed into a PostgreSQL read model, with containerised React Router 7 and PHP applications on ECS Fargate - and migrated the entire live book in one cutover.

Rubber Ring logo
Read more: Rubber Ring
Duwio workspace interface
Cloud-native SaaS platform Published 2025

Duwio

Working with Spacesuit Media, we transformed years of experience in image delivery into Duwio - a new SaaS platform for creative professionals, re-engineered from the ground up on AWS.

Built on an AWS well-architected foundation, it enables photographers and agencies to store, tag, search and deliver images seamlessly from anywhere in the world.

Read more: Duwio
GT World racing cars in motion
React Native mobile app Published 2025

SRO Motorsports Group

Si Novi partnered with Whiteflame and SRO Motorsports Group to build a new GT World app, replacing a Europe-only version with one that covers every SRO championship worldwide.

It brings together live video, timing, schedules, team data and race reminders each fan can tune to the series they follow, on a single React Native codebase over a serverless AWS backend.

Read more: SRO Motorsports Group
A package-holiday beach with sun loungers at golden hour
Serverless API rebuild Published 2025

Distribute

Distribute serves package-holiday data to a range of downstream partners through a business-critical API.

Discover how we rebuilt that API as a modern, serverless service on AWS - introducing a clean HTTP/JSON interface while keeping every existing consumer working through a zero-downtime migration.

Distribute logo
Read more: Distribute
Jaguar Land Rover tooling and equipment
Distribution web platform Published 2024

Jaguar Land Rover

Discover how Si Novi partnered with Jaguar Land Rover to build a scalable, secure AWS-powered web application for global tooling distribution.

Learn about the innovative solution, including recent enhancements for electric vehicle tooling, that supports 13 languages and over 40 regions worldwide.

Read more: Jaguar Land Rover
All case studies