Custom software, in whatever the job actually calls for

Why we don't lead with a stack

Every shop that specialises in one technology reaches the same conclusion about your project, and it is always the technology they specialise in. That is not dishonesty, it is arithmetic: it is the thing they can staff, estimate, and support. The recommendation was made before the first call.

We would rather be useful than consistent. In a single year that has meant a Laravel application, a TypeScript Shopify app, a C# integration running in a client's Azure tenant, and Rust where the workload justified it. None of those were the right answer because we liked the language. They were right because of where the data already lived, what the team could maintain afterwards, and what the thing had to do at three in the morning when nobody is watching.

The parts of a project that actually go wrong are not language-specific. Data modelling, integration boundaries, permissions, failure handling, and knowing which eighty percent to cut from v1 — those decide whether software works. Syntax is the part you can look up.

How we choose, concretely

1. Where your data and identity already live. A system that has to speak to SQL Server and Entra ID all day has an obvious answer. So does one built around an existing Postgres schema and a Laravel app your team already runs.
2. What your team can maintain after we hand off. The most expensive stack is the one nobody left in the building can read. If you have one developer and they write PHP, a Go service is a liability dressed as an upgrade.
3. What it has to do operationally. Background jobs, real-time updates, scheduled syncs, long-running imports, strict latency budgets — these narrow the field far more than taste does.
4. How fast v1 has to exist. Sometimes the correct answer is the boring one you can ship in three weeks, and revisit when it has earned the right to be revisited.

We are not paid by any platform, take no referral fees, and resell nothing. There is no version of this where the recommendation is for sale.

What we build

• Multi-tenant SaaS applications — tenant isolation, role-based access, billing, and the operational scaffolding to actually run them.
• Internal dashboards and admin tools — the systems that replace the spreadsheet-and-email workflow your operations team is silently drowning in.
• Business system integrations — CRMs, ERPs, accounting, inventory, and identity providers connected into one coherent surface, including the homegrown database no vendor will ever integrate with.
• Legacy modernization — done in increments, so the business keeps running while it happens. A rewrite that stops the company is not a modernization.
• Reporting and data work — dashboards and exports over datasets large enough that query shape and index design stop being style questions.
• API and platform work — interfaces other teams can build against without filing a ticket first.

How we work

1. Scope to a shippable v1. Every project gets carved into a three-to-six-week first cut that solves one real problem. If v1 does not earn its keep, the rest of the roadmap is theoretical.
2. Types where they pay for themselves. TypeScript on the front end, a typed backend where the language offers one, schemas at every boundary that crosses a network. Refactors stop being frightening when something else is checking.
3. Real CI from day one. Build, test, lint, deploy. No "we will add CI later." Later never comes.
4. Hand off cleanly. Documentation your team can read, a deployment they can run, and a codebase they can extend without calling us. If you need us afterwards, it should be because you want us, not because we left a puzzle.

What we work in

Listed as evidence for the argument above rather than as a brag — the point is the spread, not any single row.

Languages we have shipped production systems in

Front end

Data

Platform

Where this fits

We pair application work with custom AI integrations when the workflow calls for it, and with the ViewForge Shopify fitment platform for ecommerce. Real engagements — an advisory firm data assessment, a storefront performance investigation, and reporting platforms over tens of millions of records — are on the work page.

For a worked example of the argument on this page: ViewForge Engage is a multi-tenant Laravel application we are building, from the same team whose services page used to say “React + .NET”. The first version of it was TypeScript on Cloudflare. The language followed the job both times.

FAQ

What is your stack?

Whatever the project needs. We have shipped production systems in PHP/Laravel, TypeScript, Node, Ruby, Rust, C#, and more, with React on the front end most of the time. The honest answer to "what is your stack" is that it is the wrong question to lead with — it tells you what a shop likes, not whether they understand your problem.

Then how do you actually choose?

Four constraints, in this order: where your data and identity already live, what your team can maintain after we hand off, what the thing has to do operationally, and how fast v1 has to exist. A stack that scores well on all four is the right one. If you are a Microsoft shop with SQL Server and Entra ID, that answer is usually C#. If you have a Laravel app and one developer who knows it, adding a second language is a tax you pay forever.

We already have a stack. Will you work in it?

Usually yes, and usually that is the right call. Handing a team a codebase in a language nobody there writes is how projects get abandoned six months after launch. We will tell you if we think your existing stack genuinely cannot do what you are asking — that happens, but far less often than agencies claim.

Is a specialist not better than a generalist?

For a narrow, deep problem in one ecosystem, sometimes. For most business software, the hard parts are not language-specific: data modelling, integration boundaries, permissions, failure handling, and knowing which 80% to cut from v1. Those transfer. Syntax is the part you can look up.

Do you still do .NET?

Yes, and plenty of it — it is a genuinely good choice for enterprise B2B and anything already sitting on Microsoft infrastructure. It is just one of several things we work in rather than the thing we are. This page used to say otherwise, which is why it was rewritten.

Can you work with our existing team?

Yes. Most of our engagements are augmentation, not replacement — your repos, your standups, your review process. We can also lead a project end to end if you do not have a frontend or backend lead.