What we build, and what we don't
We do three kinds of work well. If your project is one of them, you get a team that has done it before. If it isn't, we will say so on the first call and point you somewhere better.
Web apps and internal tools
The core system a team works in all day: the one that replaced the spreadsheet, the shared inbox and the three disconnected tools. We build these as web applications (with a mobile-friendly interface where the work happens on site) on .NET and Angular, hosted on Azure or on a Linux VPS, whichever fits your budget and your IT.
Typical examples: casting and crew management, scheduling and dispatch, order and inventory handling, customer portals, internal dashboards and reporting, approval workflows.
What you get: a system designed around how your people actually work, role-based access, audit trails, exports to the formats your accountants and partners need, and documentation so the next engineer can pick it up.
Good fit when
You have 5 to 200 people whose daily work depends on a process that no off-the-shelf product models well, and the cost of errors or re-typing is visible in your month.
Not a fit when
A standard SaaS tool covers 90% of what you need. We will tell you which one.
Integrations and automation
Most companies don't need another system; they need the ones they have to talk to each other. We build the connectors, sync jobs and automation that move data between your ERP, CRM, accounting, payment provider, identity provider and partner APIs, with monitoring so you know when something stops flowing.
Typical examples: syncing customers and invoices between a CRM and an accounting system, pushing orders from a web shop into an ERP, single sign-on across internal tools, automated document generation and distribution, scheduled reporting.
What you get: integrations built as proper services (not scripts on someone's laptop), retry and error handling, logs you can read, and a runbook for what to do when a vendor changes their API.
Good fit when
Someone on your team re-types data between systems every week, or a report takes a day to assemble by hand, or a vendor integration has become a single point of failure.
Not a fit when
A Zapier or Make workflow would do. For simple, low-volume links, that's the right answer.
Platform modernisation without stopping the business
A platform that still works but can no longer be changed safely: old framework, no tests, one person who understands it. Sometimes the right answer is to modernise it in place; sometimes it is a rebuild. What goes wrong is not the choice but the execution: a big-bang rewrite that takes two years, freezes the product and ends with a second unfinished system. We have done this on a live SaaS platform with paying customers on it, and nobody noticed the switch.
How: assess what exists and what actually needs to change. Build the new platform alongside the old one, on current .NET, with CI/CD from day one. Keep both running during the migration. Migrate users or tenants in batches, verify each batch, and only then move the next. Retire the old system and its infrastructure once nothing depends on it. Then shift the team to shipping features instead of firefighting.
What you get: a platform your team can change again, a migration your customers don't notice, and no moment where the business depends on a big-bang cutover.
Good fit when
You have a working product on an ageing stack (.NET Framework, VB.NET, WinForms, an old PHP or Java app) with real users, and every change has become slow and risky.
Not a fit when
The product itself is being replaced or has no users to protect. Then a clean build is cheaper.
What we build with
We standardise on a small set of tools we know deeply rather than whatever is fashionable, because it makes the systems we hand over easier to maintain.
Backend
.NET (we build on the current release, .NET 10 today, and support whatever version you run), ASP.NET Core, Entity Framework, Microsoft SQL Server, PostgreSQL
Frontend
Angular, TypeScript, Tailwind, mobile-friendly by default
Hosting and delivery
Microsoft Azure for systems that need its services and scale; an Ubuntu VPS for systems that don't and shouldn't pay for them. Azure DevOps and GitHub Actions CI/CD, infrastructure as code, monitoring and alerting either way.