Custom software for businesses that outgrew their tools
Production web applications, internal platforms, and the APIs holding them together, for operators whose process no longer fits anything they can buy. One principal accountable, deployable software from the first week.
What this practice covers
Production web applications and the platforms underneath them. Multi-tenant systems with real access control, operational tools that replace the spreadsheet a business has outgrown, and the APIs that hold it all together. Deployable from the first week, not the last.
In practice that lands in three shapes. Multi-tenant systems, where several customers or several locations share one platform and access control has to be real rather than decorative. Operational tools, which take the process a business currently runs by hand and give it a data model, rules, and a history. And the integration layer underneath both, because the useful data is almost always sitting inside somebody else’s platform.
What is deliberately not on this list is a template site or a configured off-the-shelf product with a new logo. If the problem fits a product you can buy, the honest recommendation is to buy it. Custom is worth its cost when the process that earns the money cannot be expressed in a tool somebody else designed.
How engagements run
Discovery and delivery overlap on purpose. The traditional split, where months of requirements produce a document and the build starts afterwards, front-loads every decision to the moment you know least about the system. Instead, the first slice of working software lands early and the rest of the scope is shaped against it.
Deployable from the first week, not the last. That is the operative commitment, and it is what makes the feedback useful: reacting to a screen you can click is a different quality of input than reacting to a specification you are being asked to approve. It also means a project that goes sideways goes sideways in week three, when it is cheap, rather than at handover.
One principal stays accountable for the whole engagement. There is no account manager relaying questions to a team you never meet, and nothing is handed off to a subcontractor mid-build. You can read the longer version of that operating model on the about page.
Shipped, not proposed
Anonymized by client request. The full set of engagements we have shipped carries the problem and the build for each one.
- 01
Commercial real estate
The practice runs without a dashboard. Market briefings arrive before the day starts, pipeline and follow-up live in one system of record, and the agent fleet does the research a junior analyst would otherwise be hired for. This is the reference build for the pattern we sell: agents doing standing work, and a messaging app instead of a UI.
- 02
Multi-tenant compliance SaaS
End-to-end submission workflow live. Tenants file and track without leaving the platform. Every filing event carries a full audit trail, retained for review.
- 03
Self-storage operator
The spreadsheet is retired. Rent status across all five locations resolves in one view, RV parking included, and late fees apply consistently without the owner recalculating them.
Questions this practice gets asked
What counts as custom software rather than a configured tool?
If the shape of the work fits inside a product you can buy, buy it. Custom is the right call when the process that makes the business money does not fit the object model a vendor shipped, and the workarounds have started living in spreadsheets and in one person’s head. That is the line: not complexity, but whether the tool can represent the actual business.
Do I get working software before the end of the engagement?
Yes. Delivery is structured so something is deployable from the first week rather than the last. You should be using part of the system and telling us what is wrong with it long before the final phase, because feedback against running software is worth more than feedback against a document.
Who actually writes the code?
One principal is accountable for the engagement end to end, and the work is not handed to a subcontracted team you never meet. HDS runs an internal multi-agent platform with code review and verification gates as first-class agents, which is how a single principal runs several workstreams at once. The same platform built this site.
Can you work with the systems we already have?
That is usually most of the job. Custom work rarely arrives on empty ground, so it means talking to the billing platform, the PSA, the accounting system, or whatever else already holds the data. Typed clients and middleware over unfriendly vendor APIs are a standing part of the practice, not an add-on.
What happens to the spreadsheet we are running on now?
It gets read, modelled, and retired. The data in it is the requirements document, since it records how the business actually works rather than how someone thinks it should. Migration and the rules that were being applied by hand are part of the build, not a separate project afterwards.
Is the tool the problem, or the process it cannot represent?
Start with a free scoping conversation with Mike Hyams, the person who builds and supports the work.