Why We Build Products as Well as Client Software

Product evidence improves estimates and prioritisation

Operating products produces a better sense of where effort actually goes. The visible feature may be smaller than migration, permissions, observability, administration and support preparation around it. That experience makes estimates less likely to describe coding alone while omitting the work required for a dependable service.

It also changes prioritisation. Reliability work competes with features because both affect customer outcomes; a reduction in false positives or failed onboarding can be more valuable than another screen. We look for leading evidence-journey completion, retry rates, support causes and operational cost-rather than waiting for renewal or project failure to reveal the answer.

Metrics still require judgement. Usage can be high because a workflow is unnecessarily repetitive, and low support volume can mean users gave up. Quantitative evidence should trigger investigation, not replace conversation with customers and client teams.

Product ownership makes “done” much harder to fake

C3 Software builds tailored software for clients and maintains its own products, including WAIVERFORM and Website SpellChecker. These are not interchangeable commercial activities. Client work begins with a particular organisation and problem; product work must find a repeatable problem and serve different organisations coherently.

The reason to do both is not simply diversification. Owning a product closes feedback loops that project delivery can leave open. A feature is not done when it passes acceptance testing. It has to be discovered, understood, operated, supported, secured and changed without making the service progressively worse.

That accountability sharpens engineering judgement. It becomes difficult to call an administrative screen “internal tooling” when your own support workload depends on it, or treat cloud cost as somebody else's concern when every inefficient background job appears on your bill.

A customer request is evidence, not automatically a roadmap

In bespoke work, a client's distinctive process may be the point of the system. In a product, adding every requested variation eventually creates consulting work hidden inside one codebase. The product becomes a collection of customer-specific branches that happen to share a login page.

Good product discovery asks what job sits underneath the requested feature. Is the need common, a legitimate configurable dimension, or an exception one customer should handle outside the core product? Saying no can protect every customer, including the person making the request, from a less comprehensible service.

Configuration is not free flexibility. Every switch multiplies states to test, explain, migrate and support. We prefer configuration for durable business variation-branding, locations, document templates or scoped permissions-and a product decision where consistency is more valuable.

Products expose whether user experience is operationally correct

Product analytics and support reveal friction that a successful demonstration misses. Users abandon setup, repeat an action because its outcome is unclear, or invent workarounds around a technically complete feature. Those behaviours are not merely UX polish; they affect duplicates, support cost and trust.

Owning products encourages us to design the complete journey: the empty state before data exists, progress during slow work, recovery after interruption and confirmation that users can rely upon. A happy-path screenshot is only one state in a long-lived workflow.

Accessibility and performance follow the same logic. They are not final review items. A keyboard trap, unreadable validation message or slow tail response prevents a real subset of users completing the business outcome. The product owner owns that failure even when the underlying API returned 200.

Support changes what good architecture looks like

A system only its original developer can diagnose contains concentrated operational risk. Product ownership makes this visible quickly. Logs need correlation and tenant context; background work needs status and replay controls; support tools must explain state without granting unrestricted database access.

Observability is most useful when it answers business questions: Did the submission reach the service? Which page failed analysis? Was the external provider called? Is a retry safe? Infrastructure health alone cannot answer whether customer work is progressing.

Support also reveals where abstractions leak. If every incident requires understanding five distributed components, the architecture may have optimised deployability at the expense of comprehension. Simplicity becomes economically measurable through diagnosis time and incident frequency.

Cloud cost becomes a design constraint, not a hosting detail

In a client project, infrastructure may appear as a budget line passed to another owner. In SaaS, workload shape determines the product's unit economics. Storage retention, AI usage, rendered web pages, retries and outbound data can grow differently from revenue.

That changes design conversations. Caching is judged against freshness and isolation as well as speed. Asynchronous work needs quotas and backpressure, not unlimited autoscaling. A feature whose marginal cost exceeds its customer value is not rescued by elegant code.

Total monthly spend is a weak metric. Attribute cost to meaningful units-active tenant, completed document, page analysed or workflow executed-and watch how those units change. An architecture can scale technically while becoming commercially unsustainable.

Multi-tenancy teaches disciplined authorisation

A tenant identifier is not an access-control decision. Product systems must carry trusted tenant context through interactive requests, background jobs, caches, exports, object storage and analytics. The least obvious copy is often where isolation fails.

Product ownership therefore strengthens a habit useful in client systems too: authorise actions against a resource and scope, not just a broad role. “Admin” stops being adequate when organisations delegate template management, reporting, user administration and operational access differently.

Support access deserves explicit treatment. Convenient impersonation can conceal who actually acted. Privileged intervention should be authorised, attributable and limited to what the support task requires. Internal users are part of the threat model.

Continuous delivery means continuous compatibility

A product cannot coordinate every customer's working day around a release. Database changes must tolerate deployment overlap, queued messages may have been created by earlier code and exports or APIs may have become external contracts.

We favour small, reversible changes and expand-and-contract migrations: add the new representation, move usage, backfill and verify, then remove the old representation later. Feature flags can separate deployment from exposure, but every flag needs ownership and a deletion condition.

Backward compatibility is not always permanent. Keeping every behaviour forever prevents improvement. The product discipline is to identify the dependency, communicate the change and provide a migration path rather than accidentally breaking it or silently carrying it indefinitely.

Client engineering stops product thinking becoming inward-looking

Products can create their own blind spots. A roadmap may overvalue easily measured behaviours, assume one workflow fits every organisation or confuse existing users with the whole market. Bespoke work continually exposes us to different constraints, legacy estates and organisational realities.

Client discovery reinforces that requirements are contextual. A pattern that works for a self-service SaaS platform may be wrong for a specialist internal system with five trained users. Separate deployment may be unnecessary; deep integration or unusual audit obligations may dominate instead.

The disciplines therefore correct each other. Product work teaches lifecycle ownership and repeatability. Client work teaches close problem discovery and respect for legitimate variation. Neither justifies forcing the other into its commercial model.

Owning products makes commercial trade-offs concrete

Every capability has acquisition value, retention value, operating cost and an indefinite maintenance tax. A feature can win a sale while weakening the product if it adds disproportionate support and complexity. Revenue is evidence, but not the complete decision.

Likewise, maintenance is not failure. Dependencies need updates, threats change, browsers evolve and customers discover new edge cases. The product needs capacity for security, reliability and removal work that does not appear in a feature comparison.

This experience changes how we discuss client budgets. We expose whole-life costs, operational ownership and the trade between scope, date, cost and risk. Quietly reducing testing or supportability to preserve an optimistic plan only moves cost beyond the project's visible boundary.

The lessons we carry between both kinds of work

• Start with the outcome and evidence, not the requested noun.
• Make exceptional workflows visible before designing the normal one.
• Treat support and administration as product capabilities.
• Keep architecture no more distributed than the constraints require.
• Design tenant scope and privilege into every trusted boundary.
• Measure cost per useful outcome rather than only total spend.
• Release small changes and make consequential decisions reversible.
• Preserve data meaning and lifecycle beyond the current interface.
• Use customer requests as evidence while retaining product coherence.
• Judge launch as the beginning of ownership, not its end.

Building products as well as client software keeps our advice honest. We experience the long tail of our decisions ourselves. That does not make every decision obvious, but it makes the right questions much harder to avoid.