Services / Product Engineering
Create or improve a software product customers can use repeatedly and your team can operate confidently. We connect the user experience with account boundaries, subscriptions, integrations and the engineering needed for a dependable service.
New platforms and existing products. Clear scope. No growth or uptime guarantees.
The business case
A SaaS platform must deliver a useful recurring workflow while keeping customer information separate, commercial rules consistent and changes manageable. Problems in those foundations become support effort, revenue leakage and customer risk.
You are launching a subscription product, evolving an existing platform or preparing for more demanding customers. You need product and engineering decisions made together, with a named owner for scope, commercial rules and release acceptance.
Not every SaaS needs microservices, Kubernetes, enterprise SSO or an AI agent on day one. We build the capabilities your current audience and risk profile require, and make later expansion paths explicit.
Where we help
We scope the work against the product's stage and the evidence available. These are example engagement situations, not pre-packaged outcomes or claims about past performance.
Build the core workflow alongside account creation, plans, billing and the administration needed to operate a first release.
Start with a defined audience and value proposition; recurring billing does not establish recurring value.
Support organisations, memberships, roles and collaboration around a specific operational job, with appropriate account boundaries.
Model the organisation and permission rules before adding enterprise features.
Improve a product with fragile releases, tangled business rules, slow workflows or growing support effort, without assuming a full rewrite is necessary.
Review the running system and migrate in bounded, reversible steps.
Add grounded assistants, document workflows or bounded automation where they improve the core product, with account-aware context and measurable usage costs.
Keep entitlements, data access and consequential actions outside the model's sole control.
Scope single sign-on, audit records, provisioning, exports and customer-specific deployment needs against actual buyer requirements.
Security questionnaires and feature availability are not independent certification.
Expose versioned interfaces, handle inbound events and connect customer systems with reliable reconciliation and account-specific credentials.
External approvals, provider changes and vendor limits remain delivery dependencies.
Platform boundaries
Shared services can process work for many customers without sharing their information. Account context and permissions need to hold throughout the workflow, including background work, billing, search and support access.
The illustration represents separate account contexts, not a promise of dedicated infrastructure. The chosen isolation model is documented and verified across the relevant access paths.
Administrative tools, diagnostic records and maintenance jobs can cross ordinary product boundaries. We agree privileged access, evidence handling and safeguards rather than treating internal use as automatically trusted.
Product & commercial model
SaaS is an ongoing service, not a website with a payment form. We connect the product's recurring job to onboarding, packaging and the operating model that supports it.
Define the users, their repeat task and the outcome they need. Prioritise a complete workflow and validate assumptions with available customer and operational evidence.
Reduce the time to a meaningful first result. Account setup, invitations, sample configuration and assisted onboarding should fit the product's complexity.
Translate agreed commercial rules into features, usage allowances and upgrade paths. Prices, trial terms and limits are business decisions, not defaults we invent.
Agree useful signals such as activation, repeat workflow completion and support burden. Engineering enables measurement; it cannot guarantee retention or product-market fit.
Multi-tenant architecture
Tenancy is a design decision that affects data, identity, storage, jobs and operations. We choose shared or dedicated resources based on risk, customer requirements and cost, then verify the relevant boundaries.
Resolve the authorised account on the server and carry it through queries, file access, queues, search and exports. Never trust a browser-supplied account identifier on its own.
Compare shared tables with enforced policies, separate schemas or databases and dedicated deployments. Stronger separation can increase operational work and migration complexity.
Scope jobs, cache keys, retrieval indexes and credentials to the appropriate account. Limit expensive workloads so one customer does not consume unbounded shared capacity.
Test access with distinct users and organisations across reads, writes, downloads and administrative paths. A correct dashboard query does not prove every boundary is protected.
Identity & account administration
A person, an organisation and a subscription are different entities. Keeping them distinct makes memberships, billing ownership and account lifecycle changes easier to reason about.
Handle invitation expiry, acceptance, removal and account switching deliberately. Verify which actions an invited user can take before and after joining.
Enforce permissions on the server, with least privilege and clear ownership of privileged actions. Support access needs its own controls and audit trail.
Add SSO, domain verification and provisioning when required. Account linking, deprovisioning and recovery need explicit rules, not only a successful login demo.
Plan ownership transfer, suspension, exports and deletion. Retention obligations, billing records and customer data removal require separate, agreed handling.
Subscriptions & entitlements
We model the relationship between provider state, your commercial policy and the capabilities an account can use. Payment processing, tax treatment and customer communications are scoped against your supported markets.
Define trials, paid periods, scheduled changes, failed payments and cancellations. Grace periods and access changes follow the rules you approve.
Verify webhook signatures, deduplicate events and reconcile provider state. Handle retries and out-of-order delivery rather than assuming every event arrives once.
Check feature access and usage allowances where the action executes. Hiding an upgrade-only control is not sufficient, and a checkout success redirect is not proof of payment.
Keep usage records suitable for the pricing model and investigate discrepancies. Proration, refunds, tax and invoice behaviour depend on the provider and agreed business rules.
Integrations & platform interfaces
Customer integrations become part of your service reliability. We separate interactive requests from long-running work, make failures visible and provide a way to reconcile uncertain outcomes.
Define validation, pagination, errors, versioning and appropriate rate limits. Public interfaces need stable expectations and documentation, not internal endpoints exposed unchanged.
Store tokens securely with account-aware access, approved scopes and rotation paths. Keep secrets out of logs and provide a clear disconnect process.
Use background jobs for suitable tasks, with bounded retries, duplicate protection and dead-letter handling. Critical operations need explicit consistency decisions.
Validate formats, show row-level errors where useful and preserve provenance. Define how failed or partial imports can be resumed or reversed.
AI-enabled product capabilities
AI can support a recurring workflow without turning the whole product into an autonomous agent. We evaluate the specific task and its failure modes before choosing models, retrieval or orchestration tools.
Apply source permissions to retrieval, derived content and caches. Prevent one customer's material from becoming another customer's context or evaluation data.
Use typed interfaces and server-enforced permissions. Human approval, spend limits and stopping rules are agreed for actions that can create meaningful impact.
Check representative inputs, difficult cases and relevant regressions when models or prompts change. Keep model output quality distinct from workflow correctness.
Measure cost per workflow, cap expensive work and define useful degraded behaviour. Vendor throttling, latency and model changes remain operational concerns.
Reliability & platform operations
Operational readiness depends on the agreed workload, customer expectations and support model. We avoid premature complexity while preparing the paths that matter when something fails.
Connect application errors, traces, queues and business signals without exposing unnecessary customer data. Make account context available only to authorised operators.
Measure representative workloads and identify bottlenecks before scaling infrastructure. Track storage, compute, vendor and AI usage against the product's economics.
Agree recovery objectives, backup scope and restoration checks. A successful backup job is not evidence that the complete service can be restored.
Define escalation, customer communication and recovery responsibilities. Support hours and service levels are contractual choices, not implied by a monitoring dashboard.
Quality, security & release
Repeatable releases protect both new work and existing workflows. We establish appropriate checks around permissions, commercial rules, migrations and integration behaviour.
Test core journeys, tenant separation, role changes, billing transitions and integration failures. Prioritise coverage by impact rather than a test-count target.
Plan schema and data changes for compatibility, backfill and recovery. Breaking API or entitlement changes require communication and a migration path.
Use staging, reviewed changes, automated checks and appropriate feature flags. Rollback plans must account for data changes, not only previous application code.
Review sensitive data flows, dependencies and exposed interfaces. Legal advice, formal compliance certification and specialist penetration tests are separate scopes.
Existing platforms & migration
When customers already depend on the platform, continuity matters. We review architecture, data quality, dependencies and operational evidence before deciding what to keep, repair or replace.
Choose a bounded capability or bottleneck, add appropriate verification and migrate in stages. Keep old and new behaviour compatible where needed, with explicit data reconciliation and rollback constraints.
Use measured workload and customer requirements to justify architectural changes. More services and infrastructure can add failure modes and operating cost without improving the product's most important workflow.
Technology & frameworks
We work with sound existing foundations or select a practical combination for the product. The technologies below are options chosen by layer, not a checklist to install in every platform.
A coherent design system and an application framework suited to rendering, hosting and existing team skills; we select one framework, not all of them.
Explicit domain rules and typed interfaces. A modular monolith is often a sensible starting point; separate services follow actual boundaries.
Account-aware data access, migrations and storage permissions. Dedicated data resources are considered where customer requirements justify them.
Provider choice depends on required identity features, licensing, supported configurations and the account lifecycle.
Choose a suitable provider and merchant model for supported markets. Availability, onboarding, tax responsibilities and commercial rules need confirmation.
Durable or queued processing where appropriate, with bounded retries, reconciliation and account-scoped credentials.
Optional, task-specific capabilities with permissioned context, evaluation and usage budgets. AI is not a default requirement for every product.
Workflow checks, operational evidence and repeatable delivery with appropriate redaction, retention and access controls.
Use managed services or your existing cloud according to workload, data location and operational capacity. Kubernetes is not an assumed starting requirement.
Selection depends on provider capabilities, licensing, approved processing paths, data location and team experience. Customer assurance requirements may need additional controls or specialist assessment.
Delivery approach
Product, engineering and operations stay connected through regular demonstrations, documented decisions and explicit acceptance criteria. Work is scoped around complete capabilities rather than isolated screens.
Review the core workflow, account model, commercial rules and existing assets. Identify data, vendor and customer requirements that affect architecture.
Output: Product brief, dependency map and initial priorities.
Agree user journeys, tenancy, permissions, billing states and integration contracts. Investigate difficult dependencies and estimate a bounded release scope.
Output: Reviewed experience, architecture decisions and delivery backlog.
Deliver reviewable slices that include interface, business rules, permissions, tests and operating paths. Demonstrate progress and document scope changes.
Output: Working product increments and repeatable delivery setup.
Check isolation, commercial transitions, integrations and recovery. Resolve agreed blockers and prepare a controlled release with named operational owners.
Output: Release evidence, rollout plan and operating notes.
Review initial adoption and support evidence, refine priorities and transfer code, access and documentation. Further iteration and operations are separately agreed.
Output: Handover package and evidence-led improvement backlog.
Start with a paid two-week sprint, one agreed goal and no required long-term commitment. A first scope might validate tenancy, repair a billing path or deliver a product slice. A complete SaaS platform is not promised within that sprint.
A product decision-maker, agreed commercial rules, domain knowledge and relevant repository or vendor access. Include the owners of security, privacy, finance and customer support where their decisions affect the scope.
Scope & operating economics
Development effort is only part of the investment. Hosting, identity, payments, storage, integrations, AI usage and support all affect the operating model.
We estimate after reviewing scope, existing assets and dependencies. Changes to priority, vendor readiness or assurance requirements are discussed with their effect on time and effort. We do not assume a universal price or launch date.
Availability targets, response times, recovery objectives and maintenance responsibilities are agreed against the architecture and support arrangement. A deployed platform does not imply round-the-clock support.
Ownership & handover
Your code belongs to you from day one. We hand over the agreed implementation and operating materials so progress does not depend on one engineer or an undocumented setup.
Agreed customer workflows, account administration, subscription handling and integrations with explicit acceptance criteria and limitations.
Source code, data migrations, relevant tests and delivery configuration, with documented tenancy and permission decisions.
Release checks, observability setup, recovery notes and known issues that the people running the product can review.
Repository and account access, technical documentation and a prioritised backlog. Third-party services and components retain their own terms and licences.
Further iteration, maintenance, incident support and service levels are separately scoped. You can continue with us or transfer the work to your own team.
Related services
Start with a smaller first release, add specialist AI capabilities or review launch evidence where your product needs additional depth.
Questions before starting
An MVP focuses on the first useful product and the assumptions it needs to test. SaaS development also addresses the ongoing service model: accounts, subscriptions, entitlements, integrations, releases and operations. A SaaS MVP can include a bounded subset of these capabilities.
Yes. We review the running system, code, data and release process before recommending changes. A staged improvement or migration may be more practical than a rewrite, and we make risks and compatibility needs explicit.
There is no universal choice. Shared resources can reduce operating cost, while dedicated resources may meet specific isolation or deployment needs. We compare the requirements, enforcement model and operational overhead, then test the selected boundaries.
Yes, where the selected provider and market support the agreed model. We define states, entitlement rules, metering and reconciliation with your team. Prices, grace periods, taxes and refund policies need your approval and appropriate professional advice.
We can scope SSO and provisioning with suitable providers, including account linking and deprovisioning behaviour. Availability depends on provider capabilities, licensing and customer identity configurations.
Timing depends on the workflow, existing platform, integrations and assurance requirements. We estimate after reviewing those dependencies. A paid two-week first sprint delivers one agreed goal, not a promise to finish an entire SaaS platform.
We implement and verify agreed controls, but do not promise complete security or automatic compliance. Applicability, contracts, privacy obligations and independent assessments need qualified advisers and separately agreed evidence.
Your code belongs to you from day one. We hand over agreed assets and access, respecting licences and data rights. Ongoing maintenance, incident coverage and service levels are separately agreed, or your team can take over.
Start with the product's next constraint
Tell us who uses the product, how accounts and subscriptions work, and where delivery or operations are becoming difficult. We'll agree a practical first sprint.