It is an internal tool when
One organisation uses it
- Every user works for you
- One set of rules, one configuration
- You control when everyone upgrades
- Nobody is billed for using it
Build it simpler. Multi-tenancy you never need is pure cost.
Software product development
Building software you sell, not software you use
Products need things internal tools never do: tiers, tenants, licensing, onboarding and a way to ship without breaking existing customers. We have built both, and they are not the same job.
Book a 30-minute scoping call See the products
Bring the pricing model to the first call. It shapes the architecture more than the feature list does.
| Who is the tenant Company, site, or individual | Architecture |
|---|---|
| What separates tiers Features, limits, or seats | Architecture |
| Can a customer self-serve Sign-up without you | Architecture |
| Who hosts it Your cloud, or theirs | Architecture |
| How you ship Everyone at once, or per tenant | Architecture |
Products we have built
- Hydrajaws LimitedFree and premium tiers, one codebase
- IoT WorkzWhite-label multi-tenant platform
- Self-hosted deliveryCustomers run it themselves
- Ecommerce buildsLive in 6 to 12 weeks
Product or internal tool
The difference shows up in the architecture, not the backlog
Teams often ask for a product and describe an internal tool, or the reverse. Getting this wrong is expensive to undo.
It is a product when
Strangers pay to use it
- Customers must never see each other's data
- Tiers or seats decide what is available
- People sign up without you touching anything
- Some customers want it in their own cloud
- You ship without asking permission, and without breaking anyone
Both products below are this. One has tiers, one is white labelled and self-hosted.
Plain definitions
Two terms that get thrown around in product briefs
People nod at both and mean different things. That gap is where rebuilds come from.
What is software product development?
It is building software that strangers pay to use, which makes it a different discipline from building software your own staff use. The work includes deciding what is in which tier, how somebody signs up without talking to you, and how you ship an improvement without breaking a customer who paid last month.
The feature list is the smallest part. Pricing, tenancy and release process shape the architecture, and all three are cheap to decide early and expensive to change later.
What does multi-tenancy actually buy you?
Multi-tenancy means many customers share one running deployment while their data stays separated. You patch once, you run one set of infrastructure, and a new customer costs almost nothing to add.
The cost is that isolation has to be enforced by the system rather than remembered by a developer. Get it wrong once and one customer sees another customer's records. If you only ever expect a handful of large buyers who each demand their own instance, single tenancy is the cheaper answer and we will say so.
What we build
Six parts of a product that internal tools skip
- Tenant separation
- Data isolation enforced server side, not by a filter someone might forget. We ran multi-tenant isolation on one deployment for IoT Workz.
- Tiers and entitlements
- Free and paid from one codebase, with limits enforced where they cannot be bypassed. Hydrajaws ships exactly this.
- Identity and sign-up
- Self-service registration, single sign-on and role management. We have used Azure AD B2C and Keycloak depending on who the buyer is.
- White labelling
- Customer branding without a fork per customer, which is what makes reselling possible.
- Self-hosted delivery
- Some buyers will not put data in your cloud. The IoT Workz platform was built to be run by the customer, on Docker and Kubernetes.
- Release without breakage
- Pipelines, automated regression and a rollout you control, so one customer's upgrade is not everyone's outage.
What people ask us for
Six shapes a product build takes
These are the briefs that arrive. Most are one of them, some are two at once.
- Vertical SaaS for one industry
- Narrow, deep, sold to people who share a vocabulary. Usually built by somebody who did the job before they built the product.
- Free tier in front of a paid one
- A cut-down version that reaches the market and sells the premium tier behind it. Hydrajaws ships both from one codebase.
- White-label product sold through partners
- Customer branding without a fork per customer, which is what makes reselling possible at all. We built the white-label layer on IoT Workz.
- Self-hosted enterprise edition
- For buyers who will not put their data in your cloud. The IoT Workz platform was designed to be run by the customer on Docker and Kubernetes.
- Internal tool being turned into a product
- The most common and the most underestimated. What has to change is tenancy, identity, entitlements and release process, rather than the features.
- Platform with a device or instrument side
- Where the product is only half the value and the hardware feeds the rest. Our telemetry and instrument work sits here.
Our work
Two products, two delivery models
Case study, United Kingdom
A free tier that sells the paid one
Hydrajaws wanted their testing software to reach more of the market without giving away the paid capability. We built free and premium apps from one shared codebase with user management behind Azure AD B2C, and integrated the KTC SDK so the premium tier could read digital torque values directly from the instrument.
- Xamarin
- .NET
- Angular
- Azure AD B2C
- KTC SDK
- Increase in potential clients after launch
- 500%
- Tiers from one shared codebase
- 2
- Opened by digital torque testing
- New market
Case study, IoT platform
A platform the customer owns outright
IoT Workz was locked into a SaaS vendor: enterprise features sat behind tier upgrades, white labelling was not available, and the data was not theirs. We built a self-hosted platform on ThingsBoard with a white-label layer, Keycloak for single sign-on, a rule engine for alarms, over-the-air firmware updates and multi-tenant isolation.
- ThingsBoard
- Keycloak
- MQTT
- TimescaleDB
- Kafka
- Docker
- Kubernetes
- Platform ownership, no vendor lock-in
- 100%
- Critical alarms in live operation
- Zero
- Tenants isolated on one deployment
- Multi
How the work runs
Smallest sellable thing first
Week 1
Commercial shape
Tenants, tiers, pricing and delivery. These decide the architecture, so they come before features.
Week 2 to 4
Architecture and prototype
Isolation model, identity, and a clickable prototype of the paid path.
Week 5 to 16
Build to first customer
Aim at something one real customer can buy, not a full roadmap. Demo every two weeks.
After launch
Ship repeatedly
Pipelines, regression suite and a release process your own team can run.
Technology and integration
What we build on, and how it gets delivered
The delivery model decides most of this. We settle that before the stack.
- Application
- .NET or Node.js behind Angular or React. GraphQL where front and back end teams need to move at different speeds.
- Tenancy
- Isolation enforced at the data layer rather than by a filter in application code, so a missed condition cannot leak a tenant.
- Identity and entitlements
- Keycloak or Azure AD B2C for sign-up and single sign-on, with tier limits enforced on the server so the paid features cannot be switched on from the device.
- Billing
- We integrate the provider you choose and enforce entitlements against it. We do not write payment processing.
- Deployment
- Docker and Kubernetes, in your cloud or in your customer's. Helm and pipelines handed over so your team runs releases without us.
- Data and monitoring
- PostgreSQL or SQL Server, TimescaleDB where the product ingests readings, Grafana for what operations needs to watch.
Who does the work
Twenty engineers, eight of them senior
Product work needs somebody who will argue with you about scope. A team of twenty has no room for people who quietly build whatever the last email asked for.
- Engineers in Ho Chi Minh City
- 20
- Senior engineers
- 8
- Average experience
- 5+ yrs
- Working with US, UK and EU teams
- 10+ yrs
You interview whoever we put forward. Ask what they would cut from your first release, and see whether the answer is specific.
How we work
Five engagement models, and you pick how much you keep
The models differ in one thing: how much of the management you hand over. Everything else, including who owns the code, is the same in all five.
Changing model later is normal. Augmentation into a dedicated team is the common direction, and the people stay.
Engineers join your team and work inside your process, your board and your code review.
- Team control
- You manage the day to day
- Pricing
- Monthly per person, by role and seniority
- Minimum
- 1 month
A team that works only on your product, with a lead on our side running delivery.
- Team control
- Shared. Our lead runs delivery, you set priorities
- Pricing
- Monthly per role, lead included
- Minimum
- 3 months
A long-term engineering site under your standards, where we carry recruitment, HR, payroll and equipment.
- Team control
- You direct the work, we run operations
- Pricing
- Monthly per role plus site costs
- Minimum
- 6 months
04
Fixed Price
One price for a scope that is genuinely settled, with the overrun carried by us.
- Team control
- We deliver, you accept against written criteria
- Pricing
- Fixed bid, paid against milestones
- Minimum
- Project based, usually 10 to 14 weeks
Everything in the centre model, with the whole team moving into your own Vietnamese entity on an agreed date.
- Team control
- Transfers from us to you
- Pricing
- Monthly per role, transfer price agreed up front
- Minimum
- 2 to 6 years
FAQs
Questions we get on the first call
Should we start with an MVP?
Start with the smallest thing one real customer would pay for. That is usually narrower than an MVP as normally scoped, and it tells you more.
Multi-tenant or one deployment per customer?
Multi-tenant unless buyers demand their own instance. We have built both, including a platform designed to be self-hosted by the customer.
Can you build the free tier and paid tier from one codebase?
Yes, that is how the Hydrajaws apps work. Entitlements are enforced server side, so the paid features cannot be switched on from the device.
Do you handle billing?
We integrate the billing provider you choose and enforce entitlements against it. We do not build payment processing from scratch.
Who owns the product?
You do, entirely, including the code and the intellectual property.
Can you keep working on it after launch?
Yes, either as a dedicated team or a support arrangement. Or you take it in house and we hand over.
What does a first sellable version cost?
The smallest thing one real customer would pay for is usually 10 to 14 weeks. Tiers, tenant isolation and self-service sign-up add to that. Self-hosted delivery adds more again, because you are then shipping something a stranger has to install. Pricing follows the engagement model above rather than a published project price.
How do you stop the product forking per customer?
By making configuration do the work that a fork would otherwise do. Branding, feature flags and tenant settings cover most special requests, and anything left goes on the roadmap or gets declined. One codebase per customer is the failure mode that quietly ends product companies, and it starts with a single reasonable exception.
What about customers in other countries wanting their data local?
Handled either by deploying a regional instance or by shipping the self-hosted edition, and the choice depends on how many such customers you expect. We built IoT Workz so the customer runs it themselves, which removes the question entirely at the cost of a harder release process.
Bring the pricing model, not just the feature list
How you plan to charge tells us more about the build than a backlog does. Thirty minutes and you will have an architecture sketch.