Software engineering and IT services
We build the software your business runs on.
Windows desktop applications, web and mobile apps, cloud systems, and the integrations that hold them together. A small senior team that owns delivery from first call to handover.
You talk to the engineer building it. You own the code and the repositories from day one. Scope is quoted before work starts.
fig. 01 — a system shape we build most weeks
What we can show you instead of a logo wall
Industries we have delivered in
Eight sectors where we have shipped working systems, not sectors we would like to enter.
Technologies we work in daily
The areas of real depth first. The supporting stack is on the technologies page.
Six things we are hired to build
All servicesWindows desktop software
WPF and .NET line-of-business apps, internal tools, kiosk and offline-first systems.
Web application development
Customer portals, operational dashboards and internal platforms that hold up under real use.
Websites and CMS
Marketing sites, e-commerce and headless or WordPress builds your team can actually edit.
Mobile apps
iOS and Android, cross-platform where it fits and native where it does not.
API and system integration
Connecting CRMs, ERPs, accounting and third-party services, and automating what sits between them.
Cloud, DevOps and maintenance
Migration, hosting, CI/CD, monitoring and the ongoing support that keeps it all boring.
How we work, condensed
Four stages before anything is built, then two-week cycles until you sign off. The full sequence, including QA and handover, is on the process page.
- step 1
Discovery
We learn the process before we discuss software. Usually one or two sessions and some watching.
- step 2
Proposal and estimate
Written scope, assumptions, exclusions, a phase plan and a range. You can take it to another vendor.
- step 3
Design
Data model, architecture and the key screens, agreed before build starts.
- step 4
Build in sprints
Two-week cycles, each ending with something you can open and use.
The stack, by where it sits
Microsoft stack
Our deepest area. Desktop, APIs and data layers on .NET, running in production for businesses that live in a Windows environment.
Web and front end
Interfaces for portals, dashboards and platforms, built with the framework your team can maintain after we leave.
Mobile
Cross-platform where it fits, native where the hardware demands it, offline capture where the job happens away from signal.
Cloud and data
Hosting, pipelines and databases, defined in code so an environment can be rebuilt rather than remembered.
Integrations
The connective work: CRMs, ERPs, accounting systems, learning platforms and third-party services that need to agree with each other.
Where we have worked
All eight industriesHealthcare
Clinical desktop tools and plugins that sit inside the practice software a clinic already runs.
.NET / WPF / SQL Server
Retail and merchandise planning
Inventory, forecasting and planning systems, plus the reporting layer everyone argues about.
.NET / SQL Server / Excel interop
Education and e-learning
Learning platforms, LMS builds and customisation, course delivery and the integrations around it.
Moodle / PHP / Laravel
Nonprofit
Automation pipelines, content and workflow tooling for teams doing too much with too little.
Python / Node.js / cloud functions
What working with us is like
We would rather tell you how we operate than show you quotes you cannot verify. Everything here is how a project actually runs.
You talk to the engineer building it
No account manager relaying requirements. The person writing the code is in the call, which is why answers arrive the same day.
A working build every two weeks
Not a status report. An installed application or a staging URL you can open and use, from the second sprint onwards.
You own the code and the repositories from day one
Repositories, cloud accounts, certificates and store listings are in your name. We work inside your accounts, not ours.
We quote scope before we start
Written scope, assumptions and exclusions, agreed before a line is written. If something falls outside it, you hear about it before the work happens, not on the invoice.
We hand over documentation, not a shrug
Architecture notes, setup steps, deployment process and the decisions we made and why. Enough for another team to pick it up.
We tell you when not to build something
Sometimes the answer is a configuration change, an off-the-shelf product, or nothing at all. Saying so costs us a project and keeps you as a reference.
Four ways to engage us
Each has a trade-off. We will tell you which one fits your situation, including when the answer is the cheaper one.
Fixed scope
A defined piece of work with a written specification, a fixed price and a delivery date.
best when the requirements are clear and unlikely to change much.
trade-off changes need a variation, so it rewards spending real time on scope up front.
Dedicated team
One or more engineers assigned to you for a period, working from your priorities.
best when the work is ongoing and priorities shift week to week.
trade-off you carry the planning load, and you pay for capacity rather than output.
Staff augmentation
We add senior engineers into your existing team and your existing process.
best when your team is capable but short-handed, or missing one specific skill.
trade-off we work inside your standards, so delivery speed depends on your process too.
Support retainer
A monthly arrangement covering monitoring, patching, fixes and a pool of change hours.
best when software is live and needs to stay healthy without a full-time hire.
trade-off large new features do not fit inside it and get quoted separately.
Rough out a timeline in thirty seconds
Pick the shape of the project and we will show the range we usually see. It is a ballpark. Real numbers come after a call, once scope is written down.
No pricing here on purpose. A number without scope behind it is a guess, and we do not quote guesses.
Most of the risk in a web build sits in permissions and reporting, not in the interface. Integrations with your existing systems are quoted separately.
Get a real estimate on a callThe questions we get asked first
Fixed price for defined scope, day rate for ongoing work. Either way you get a written scope with assumptions and exclusions before anything starts. We do not publish rates on the site because they depend on the engagement shape, and we would rather quote your actual project than have you compare a number out of context.
You do, on delivery and in writing. Repositories are in your organisation from the first commit, not transferred at the end. Any third-party libraries we use are permissively licensed, and we list them so your legal team can check.
We hold a working overlap with US Eastern hours through your morning and with UK hours through your afternoon. Standing calls sit inside that overlap. Anything urgent has a documented escalation path rather than a hope that someone is awake.
Yes, before discovery. We will sign yours rather than insisting on ours. If your procurement needs a data-processing agreement or security questionnaire, send it over early because those take longer than the contract itself.
Fixed-scope projects are billed in phases, so you are never more than one phase exposed. If a phase misses what was agreed, we fix it at our cost. If you want to stop, you keep everything built to that point, including the repositories and documentation, and we will brief whoever takes over.
Handover is part of the build, not a final gesture. You get architecture notes, environment setup steps, the deployment process, a decision log, and a walkthrough call recorded for whoever joins later. We assume the person reading it has never spoken to us.
Roughly three to four weeks of engineering. Below that we are honest that our overhead is not worth your money, and we will usually point you at a freelancer or a configuration change instead.
Often, and it is usually the best arrangement. We work inside your repositories, your review process and your standards. We will flag process problems once, then work with what you have.
Yes, after a review. We read the codebase, run it, and give you an honest assessment of what it will take to support and extend. Occasionally that assessment is that a rewrite is cheaper, and we show the reasoning rather than just asserting it.
More than you might hope. We need a decision maker available for a weekly call and someone who can answer domain questions within a day. Projects that stall almost always stall on access to people, not on engineering.
Tell us what is not working and we will tell you what it takes to fix it.
A first call is thirty minutes, free, and ends with an honest read on scope, sequence and whether we are the right team for it.