Software Development
The systems a business runs on rather than the page it advertises with: client portals, admin dashboards, booking and scheduling, integrations, and the internal tools that replace a spreadsheet nobody trusts any more.
The problem this solves
Most businesses reach a point where the work has outgrown the tools. Three people edit the same spreadsheet. A job moves between an inbox, a WhatsApp thread and a whiteboard. Someone re-types the same customer details into a third system every afternoon.
None of that is a website problem. It is a software problem, and off-the-shelf tools usually solve eighty per cent of it while making the last twenty per cent permanently awkward.
What we build
- Admin dashboards — the internal view of what is happening right now, with the filters and permissions your team actually needs
- Client and customer portals — documents, status, invoices and messages in one place instead of scattered across email
- Booking and scheduling — availability rules that match how the business really works, including the exceptions
- Workflow tools — the small application that removes a recurring manual job
- APIs and integrations — connecting a CRM, accounting package, payment provider or calendar so data stops being re-keyed
How we approach it
We start from the job being done badly today, not from a feature list. The first version does one thing completely rather than five things partly, because a tool nobody trusts gets abandoned and a tool that nails one job gets used every day.
Integrations are scoped up front, because that is where this kind of project overruns. An API with poor documentation, a rate limit nobody mentioned, or a data model that disagrees with yours can cost more than the feature it supports.
Technologies
Next.js and React on the front end, Node.js APIs, PostgreSQL or MongoDB for data, Prisma where an ORM earns its place, and deployment on Vercel or AWS with Docker where the environment needs to be reproducible. Payments through Stripe. Nothing exotic — the stack is chosen so you can hire someone else to maintain it.
What you get
A working application in a repository you own, deployed to infrastructure in your accounts, with environment configuration documented and a handover that covers how to run, change and monitor it. Plus the tests and error reporting that make a change on a Friday survivable.
Who this is for
Businesses with a process that has outgrown spreadsheets and email, SaaS teams that need engineering capacity for a specific module, and founders with a product idea that needs to exist before it can be sold.
Related work
The booking flow concept study shows how we handle constraint solving across rooms, staff and equipment — the kind of availability logic that most booking widgets push onto the customer.
If the product itself is the thing you are selling, SaaS development covers tenancy, billing and onboarding. If it needs a model in the loop, AI development is the other half.
Frequently asked questions
- What counts as custom software rather than a website?
- If people log in, data changes, or a process runs through it, it is software. Dashboards, portals, booking systems, admin tools and integrations are all applications, even when they live at the same domain as a marketing site.
- Can you work on an application we already have?
- Yes. A large share of our work is extending existing systems: adding a module, replacing a slow part, fixing an integration, or taking over a codebase after the original developer left. We start with a short audit so nobody guesses at the state of the code.
- How long does a first version take?
- Four to eight weeks for a single module or MVP scope, depending on integrations. Larger systems are split into phases that each ship independently rather than one long build with a single release date.
What is included
- Web applications and admin dashboards
- Client and customer portals
- Booking, scheduling and workflow systems
- APIs and third-party integrations
Reading on Software Development.
Website, web app, or SaaS — which one do you actually need?
The three are different in cost, timeline and risk. A short decision guide, and the questions that tell them apart before you brief anyone.
Booking flow for a multi-room clinic
A concept study in reducing a five-screen booking journey to two, without losing the availability rules a real clinic needs.
Tell us what you are building.
Send us the problem — an idea, an existing product, a site that is not performing. We will tell you what is worth building, what is worth fixing, and what it costs, before anyone signs anything.