The systems that run behind the website
Web applications, APIs, dashboards and integrations — in ASP.NET and the other stacks we work in. The software nobody sees, that everything else depends on. Fifteen years of it, across more languages than any one project needs.
What we build
Web applications
Internal tools, customer portals, booking and quoting systems — the things a CMS can technically be forced to do, and shouldn’t be.
APIs and integrations
Connecting systems that were never designed to talk to each other: a CRM to a store, an ERP to a website, a payment provider to an internal ledger.
Dashboards and reporting
Pulling numbers out of several systems into one screen people will actually open, with the data refreshed on a schedule you control.
Automation
Scheduled jobs, data imports and exports, document generation — the manual work somebody is currently doing by hand every week.
Licensing and distribution
Software you intend to sell: licence keys, activation limits, update delivery and payment verification. We’ve built the whole chain for our own products.
Taking over existing software
A developer left, or the system has outlived its original author. We’ll audit it and tell you honestly whether to extend it or replace it.
How we pick a stack
We work in ASP.NET, PHP, JavaScript and Node, and across SQL and NoSQL databases. Which one a project gets depends on three things, in this order:
- What it has to integrate with. A system that lives inside a Microsoft estate is usually an ASP.NET project, whatever else would have been fun to build.
- Who maintains it after us. If you have an in-house developer, we build in what they know. Handing someone an unfamiliar stack is how software gets abandoned.
- What the problem actually needs. Only then. Most business software is not technically exotic, and choosing something exotic for it is a cost you pay forever.
We will say when a project doesn’t need custom software at all — when an off-the-shelf product, properly configured, would do it for a fraction of the price.
What you get
- Full source code, yours to keep
- Documentation of how it works and how to extend it
- Deployment instructions, and deployment if you want it
- A test suite where the logic justifies one
- A security review before anything goes live
- A defined support window after launch
Software needs maintaining more than a website does — dependencies age, platforms deprecate, security advisories arrive. That can run under a care plan, or you can handle it.
How a project runs
Scoping
What the system does, who uses it, what it connects to, and what happens when it’s unavailable. That last question changes the architecture more than any other.
Written spec and fixed quote
Functionality, data model, integrations, and what’s explicitly out of scope.
Build, with something usable early
You get a working version well before it’s finished. Direction changes are cheap then and expensive later.
Test, review, deploy
Tested against real data, security-reviewed, deployed, documented. Then a support window while it meets actual users.
Common questions
Do we own the code?
Yes. Full source on final payment, and you can take it to any other developer. We keep ownership of our own pre-existing libraries and grant you a perpetual licence to use them as part of your system.
Can you work with our in-house developers?
Regularly. We’ll match your conventions, your repository and your review process rather than imposing ours.
What if we only need part of it built?
That’s common and usually sensible — we build the hard integration layer and your team builds the interface, or the reverse.
How do you handle sensitive data?
Encrypted in transit and at rest, least-privilege access, no production data in development environments, and secrets in configuration rather than source control. If you’re subject to a specific regime, tell us at scoping, not at launch.
Can you build software we’ll sell to others?
Yes, and that’s a speciality. Licence keys, activation limits, update delivery, payment verification and refund handling — we built and run that whole chain for our own products.
Tell us what the system has to do
A paragraph is enough to start. We’ll come back with whether it’s a fit, a rough size, and what we’d need to pin down before quoting.