C3 Software
From Bespoke Development to Cloud SaaS: The C3 Software Journey
Building cloud SaaS alongside bespoke client software changes the engineering contract. Delivery becomes continuous ownership of onboarding, tenancy, operations, support, cost and product decisions.
SaaS is not bespoke software with a subscription
C3 Software has more than 25 years of software contracting experience and now combines client work with its own software portfolio, including WAIVERFORM and Website SpellChecker. That evolution is sometimes described as a change in commercial model. Technically, it is a much deeper change in responsibility.
A bespoke project can optimise for one organisation's workflow, release calendar and operating environment. A SaaS product must serve different customers on one evolving service without allowing their data, configuration or workload to interfere. The product team owns the consequences continuously; there is no handover point at which deployment stops being part of development.
Putting an application in the cloud does not make it SaaS. Multi-tenant isolation, repeatable onboarding, self-service administration, continuous upgrades, observability, support and sustainable unit economics are product capabilities. Missing any one of them eventually turns growth into manual work.
Client work and product work optimise for different truths
In bespoke development, one client's requirement can justify a feature. In product development, a request is evidence, not automatically a roadmap item. The team must identify the underlying problem, determine how widely it applies and decide whether configuration can express legitimate variation without making the product incoherent.
The dangerous phrase is “just make it configurable”. Each option multiplies combinations to test, document, migrate and support. Configuration is valuable when customers genuinely differ along a stable dimension. It is harmful when used to avoid making a product decision.
Client deadlines can define release scope. A product roadmap has to balance acquisition, retention, reliability, security, support load and strategic direction. Revenue attached to one request does not reveal the long-term maintenance cost it imposes on every future release.
Product ownership closes the feedback loop
Owning a service means seeing problems that a delivery-only view can hide. A feature is not complete when the code works; it is complete when customers discover it, understand it, use it successfully and can recover when it fails. Onboarding copy, administrative tools and support diagnostics are therefore engineering work.
Support conversations are product research, but they need interpretation. The person who contacts support represents users who noticed a problem and chose to report it. Usage telemetry reveals different gaps: abandoned journeys, repeated actions, slow stages and features that nobody finds. Neither source alone tells the whole truth.
A product team must also remove features. Every capability creates an indefinite tax on testing, permissions, documentation and cognition. Deprecation is not housekeeping; it is how a product protects its ability to change.
Multi-tenancy is an authorisation concern before it is a database concern
Teams often begin tenancy discussions with shared versus separate databases. The first question should be: how does every trusted operation establish the tenant context, and how is cross-tenant access made difficult by construction?
A tenant identifier supplied by a browser is not proof of membership. Derive authorised context from trusted identity and membership data, enforce it in application and data-access boundaries, and include tenant scope in background jobs, caches, object storage, search indexes and telemetry. Most isolation failures occur away from the obvious query path.
Per-tenant databases offer stronger isolation and restoration options but increase provisioning, migration and fleet-management work. Shared storage improves density but demands disciplined query filters and noisy-neighbour controls. The correct choice depends on isolation requirements, customer count, workload variance and operating capability-not a claim that either model is inherently SaaS-ready.
Continuous upgrades make compatibility a product feature
A single SaaS service avoids supporting many installed versions, but it moves compatibility work into every deployment. Database changes must tolerate rolling application versions. Queued messages may have been produced by older code. Public APIs and exports can become customer dependencies even when the team did not intend them as permanent contracts.
Expand-and-contract migrations are safer than destructive changes: add a compatible representation, move readers and writers, backfill and verify, then remove the old form later. Feature flags can separate deployment from exposure, but flags need owners and expiry dates or they become a shadow versioning system.
Backward compatibility is not always the correct promise. Sometimes coordinated change is cheaper than indefinite support. The important part is recognising contracts before breaking them and giving customers an observable migration path.
Operations becomes part of architecture
For SaaS, an architecture diagram without deployment, monitoring and recovery is incomplete. The system needs to reveal which tenant and journey are affected, whether work is delayed or lost, and whether retry is safe. Infrastructure uptime does not prove that registrations, scans or reports are progressing.
Background processing requires explicit semantics. At-least-once delivery means handlers must be idempotent. A dead-letter queue stores failed work; it does not resolve it. Operators need context, replay controls and a way to distinguish a poison message from a temporary dependency failure.
Backups are only potential recovery. Restore exercises validate recovery time, credentials, runbooks and data integrity. SaaS teams own these rehearsals because a customer cannot reinstall yesterday's database when the shared service fails.
Cloud elasticity does not guarantee good economics
Cloud platforms reduce provisioning friction, but easy consumption can conceal poor unit economics. Costs may follow pages scanned, documents stored, AI tokens, background retries, outbound traffic or long retention periods. Total monthly spend says little unless it can be related to customer and workload behaviour.
Measure cost per meaningful unit and protect expensive routes with quotas, concurrency limits and backpressure. Caching can reduce expense only when freshness and tenant isolation remain correct. Automatically scaling a wasteful operation merely spends money faster.
Pricing and architecture influence each other. An “unlimited” promise creates an engineering liability if one customer's workload can dominate shared resources. Product packaging should reflect real cost drivers without exposing customers to an incomprehensible cloud bill.
Security work expands with self-service
Bespoke administrators may be trained employees on a private network. SaaS onboarding exposes identity recovery, invitations, billing-adjacent administration and data export to a broad public threat model. Rate limiting, abuse detection, secure defaults and auditable privilege changes become central behaviours.
Customer administrators are powerful but not omnipotent. Separate product operations from tenant administration, require explicit authorisation for support access and record who accessed or changed sensitive data. “Admin” is too blunt once organisations delegate real responsibilities.
Data lifecycle also becomes product design. Retention, export and deletion must account for primary storage, derived reports, object storage, caches and backups. Promising deletion is easy; engineering a defensible lifecycle is not.
The product is also the operating organisation
SaaS maturity is sometimes presented as a list of technologies. The harder transition is organisational. Somebody must own incidents, vulnerabilities, customer communication, cost anomalies, roadmap choices and the removal of obsolete behaviour. Automation amplifies clear ownership; it does not replace it.
Combining products with client work is valuable because the disciplines inform one another. Bespoke work sharpens discovery and respect for operational variation. Product ownership sharpens attention to lifecycle, repeatability and support. The danger is applying the wrong commercial reflex: customising a product for every request or treating a client system as a generic platform before its needs are understood.
The journey from bespoke development to cloud SaaS is therefore not an abandonment of tailored engineering. It is learning where variation creates customer value, where standardisation protects the service and where long-term ownership changes the meaning of “done”.
Onboarding and support determine whether growth is scalable
A bespoke team can configure environments through project knowledge. A SaaS product needs repeatable provisioning, sensible defaults, validated configuration and clear progress when setup is incomplete. Every manual onboarding step creates delay, variation and a future support dependency. Automate stable operations, but preserve an auditable route for exceptional cases rather than pretending exceptions will disappear.
Self-service does not mean abandoning customers to documentation. It means designing the common journey so that customers can succeed without privileged intervention, while giving support enough safe context to resolve unusual failures. Impersonation is convenient but dangerous: prefer explicit, logged support access and tools that expose state without unnecessarily exposing customer content.
Measure time to first value, not merely account creation. A registered tenant that never completes its first meaningful task is not onboarded. The same principle applies to feature adoption: availability in a menu is an output; repeated successful use is the outcome.
Product metrics need the same discipline. Monthly users can rise while completion deteriorates, and support volume can fall because customers have disengaged. Pair adoption measures with successful outcomes, failure rates, retention and service cost. Metrics should challenge a roadmap narrative, not decorate it. Owning the product means being willing to discover that a shipped feature did not earn its permanent place.