Ship the platform work your roadmap keeps deferring
Willowark builds the platform layer inside SaaS products: tenant isolation, usage metering and billing, the integration surface enterprise deals demand, and the database work that starts when the primary instance becomes the bottleneck. Your engineers could build all of it. What we remove is the capacity problem, because platform work rarely outranks features on a roadmap and gets more expensive every quarter it waits.
We work as senior contract engineers inside your process: your repo, your CI, your review standards. A typical engagement is one to three engineers owning a bounded workstream — the isolation refactor, the metering pipeline, the move off the shared schema — starting with a design doc your team tears apart, then incremental pull requests they review.
A first engagement is usually overflow on a roadmap item that has been deferred at least twice: the SAML and SCIM work an enterprise deal is waiting on, a connector your largest customer needs, or the metering rewrite finance has been asking about. We scope it against your codebase before quoting it, ship in small reviewed pull requests, and hand it back documented. If it goes well, the second engagement is typically the larger platform workstream — the isolation refactor or the database work — that nobody could justify starting cold.
Reviewed
Sound familiar?
If you've said any of these, we should talk.
“We all know the database is the bottleneck. Nobody has a quarter to spend on it.”
We take it as a workstream, measurement first: slow query and lock analysis, then index and access-pattern fixes, then structural work — partitioning hot tables, moving heavy reads to replicas, sharding by tenant. Each step ships independently under load, so relief arrives early rather than behind one risky cutover.
“Every enterprise deal stalls on SSO, SCIM, audit logs, and a security questionnaire.”
We build the enterprise tier as infrastructure rather than per-deal patches: SAML and OIDC with per-tenant identity provider config, SCIM provisioning and deprovisioning, role-based access control, and tenant-scoped audit logs that are queryable and exportable. We write the technical documentation reviewers ask for.
“What we invoice and what customers actually use have drifted apart.”
Usually the meter and the entitlement logic evolved separately. We build one metering path: usage events emitted at the boundary with idempotency keys, aggregation that survives retries and replays, an entitlement service the product checks, and reconciliation against what the billing provider charged.
“Onboarding a customer costs us two weeks of engineering per integration.”
That is a framework problem. We build the integration platform once — a connector interface with shared auth, rate limiting, retry and backoff, dead-letter handling, and replay — plus signed outbound webhooks. New connectors become configuration and a small adapter instead of a project.
“Every release is an all-hands event. Nobody wants to deploy on a Friday.”
Release fear is usually a missing pipeline, not a missing process. We put the mechanics in place: trunk-based flow with feature flags, automated migrations that run forward and back, canary or blue-green deploys with health checks, and alerting tied to the paths that matter. Deploys become small, frequent, and boring.
How this industry actually runs
The operation as we usually find it.
A SaaS engineering org is almost always smaller than the surface it maintains. Product squads own features, one or two people own infrastructure, and everyone is on call. Decisions made in year one — a shared schema, a single Postgres, a job queue used as an integration bus — hold until one large customer turns them into a weekly incident. Meanwhile go-to-market pulls engineering sideways: a deal needs SAML and SCIM, a questionnaire needs tenant-scoped audit logs, and finance has noticed that invoiced usage and metered usage no longer agree.
Product, integrations, and the AI feature behind them
Components:
- Your product (web, mobile, API)
- Backend services (queues, jobs, evals)
- AI feature (retrieval, review gates)
- Data & integrations (warehouse, third parties)
Connections:
- Your product to Backend services (API)
- Backend services to AI feature (structured calls)
- Backend services to Data & integrations
What we build
Starting projects that fit SaaS & Software Products.
- Multi-tenant architecture, per-tenant limits, and noisy-neighbor containment
- Usage metering and billing pipelines with idempotent aggregation and entitlements
- SAML and OIDC SSO, SCIM provisioning, RBAC, and tenant-scoped audit logging
- Connector frameworks, signed webhooks, retries, dead-letter queues, and replay
- Database scaling: indexes, partitioning, read replicas, and tenant sharding
- Zero-downtime migrations with dual writes, shadow reads, and flagged cutover
- Production-grade AI features with retrieval, evaluation, and per-tenant cost controls
- CI/CD hardening with feature flags, canary deploys, reversible migrations, and production observability
Capabilities we bring
Related work
Where this is running today.
AI operating software for training operations
A global automotive manufacturer's training operation · Automotive
AI operating software for training operations
AI operating software for the manufacturer's training schedulers — removing manual scheduling labor and logistics tracking, saving hundreds of hours per year — plus a training video game built to help trainers perform better. Used across the manufacturer's training organization.
Read the case study →Global loyalty & rewards platform modernization
A global loyalty & rewards platform · Financial services
Global loyalty & rewards platform modernization
Engineering with the platform's global loyalty and rewards teams: migrating legacy systems to event-driven microservices in Go, across point tracking and the ledger — distributed systems work through to war-room production deployments.
Read the case study →Working in SaaS & Software Products?
Tell us the line.
What runs by hand, what is not connected, what you are trying to build. An engineer replies within one business day with whether and how we would approach it.
Common questions
What SaaS & Software Products teams ask first.
We already have good engineers. What does contract engineering actually add?
Capacity that arrives productive on work you have already scoped but cannot fit, and depth in disciplines most product teams do not staff full-time — distributed systems, cloud architecture, data pipelines, AI integration. We take a workstream off the board and leave it maintainable by your engineers.
How do you migrate a live system with no maintenance window?
Incrementally, with the existing path still serving traffic. The new implementation runs in shadow, consuming the same inputs while its outputs are compared against production. Once differences are explained, traffic moves a slice at a time behind a flag, with rollback as one config change.
What does an engagement look like structurally?
Three shapes: a scoped project with a defined outcome, contract engineers embedded with your team, or fractional technical leadership when you need architecture depth more than headcount. All start with a short diagnostic against your code and your metrics, then a written plan you approve.
Do you work in our stack, or do you bring your own?
Yours. We work most often in TypeScript, Python, and Go on Postgres with a queue and a major cloud provider, and we are comfortable in Java, .NET, and Ruby codebases as well. What matters more than the language is the shape of the system — tenancy, data model, deploy pipeline — and we usually spend the first days reading before proposing anything. If your stack is unusual enough to slow us down, we say so before you commit.
What happens when the engagement ends? Will our team be able to maintain what you built?
That is the design goal from the first pull request. Everything ships through your review process, in your conventions, with design docs and runbooks in your repo rather than ours. Toward the end of a workstream we typically pair your engineers onto the on-call and change paths for the new system, and we stay available for a defined period afterward. If your team cannot operate it without us, we consider the work unfinished.
Strategy. Software. Systems.
Engineering for SaaS & Software Products.
Describe the problem in your own words. An engineer reads it — not a sales script — and tells you plainly what it would take.