SV Services
Six disciplines we ship and operate.
If a capability is not on this page, we do not claim it. Every one of these is something we have built, put into production, and still run.
/ Platforms we integrate
02 Disciplines
Custom application development
We build web platforms for businesses that have outgrown spreadsheets, shared inboxes, and off-the-shelf tools that almost fit. That usually means multi-tenant architecture with strict data isolation, a permission model that survives contact with a real org chart, and workflow that matches how the business actually operates rather than how software wishes it did.
We have shipped subscription billing, white-label branding per customer, audit trails, document handling with electronic signature, and administrative tooling that non-technical staff use every day without training.
Systems integration
Most businesses do not need one more system. They need the systems they already pay for to talk to each other. We connect partner and supplier APIs, point of sale exports, payroll and scheduling providers, and mail platforms, then keep those connections running.
In production this has meant single sign-on against Microsoft Entra ID, outbound mail through the Microsoft Graph API so messages come from the real mailbox, Cloudflare for wildcard DNS and R2 object storage, and Stripe subscription billing reconciled against webhooks so the platform and the payment processor cannot silently disagree.
It has also meant the unglamorous parts: HMAC-signed partner requests across separate staging and production environments, inbound webhooks whose signatures are verified before the payload is trusted, and delta-aware polling that reports a received count on every run so a silent failure cannot hide.
Single sign-on across many subdomains is a good example of the detail involved. Rather than registering a redirect URI per tenant, one URI serves all of them and the originating host travels through the callback in a short-lived encrypted cookie, so a user lands back where they started.
Data engineering and reporting
Import pipelines that stream rather than load everything into memory, deduplication keys chosen so that re-importing a file does not silently create a second copy of the truth, and reconciliation between sources that disagree on purpose.
On top of that: dashboards, period comparisons, ranked league tables, and forecasting. When money depends on a number, we build the audit trail that lets someone prove where it came from.
Mobile
Native and cross-platform applications, plus the APIs behind them. We build both sides, which means the API is designed for the screens that consume it instead of being a database exposed over HTTP.
Shipped: bearer token authentication, sign-in with Apple, Google, Facebook and Discord, device registration and trust, biometric unlock, push to both platforms from one FCM v1 pipeline at parity, in-app account deletion, and field tooling that keeps working when the signal does not.
We have taken applications through Apple App Store and Google Play review, so we build for it from the first commit: Sign in with Apple alongside any other social provider, private relay addresses handled properly, a real account-deletion route, a Data safety declaration that matches what the app actually transmits, and a defensible justification for every sensitive permission. Background location is the usual sticking point.
Automation
Work that should not need a person: scheduled imports, background jobs on managed queues with retry and dead-letter handling, structured data collection, and alerting that reaches someone through the channel they actually read.
The point of automation is not that it runs. It is that it tells you clearly when it did not.
Infrastructure and hosting
We run what we build. Reverse proxied web tiers, process supervision for queue workers, Cloudflare DNS with wildcard subdomains and DKIM, SPF and DMARC configured for deliverability, Cloudflare R2 for uploads on tenant-scoped paths, Redis for queues and caching, Sentry for errors tagged by customer, certificate renewal, and backups that have been restored at least once on purpose.
Because we operate the software, we design it to be operable. Those are not separate activities.
03 How we work
Small team,
direct line.
You talk to the people writing the code. There is no account layer between the brief and the build, which is the main reason things get built the way they were described.
We start by learning the operation, not the feature list. Most of the value in a custom platform comes from modelling the business correctly at the beginning, and most of the cost of getting it wrong shows up two years later when the workarounds have become policy.
We ship in working increments and put them in front of real users early. Software that has never been used by the people it was built for is a hypothesis, not a deliverable.
After launch we stay on. Platforms that handle money, schedules, and customer records need someone who knows them when something changes upstream, and something upstream always changes.
See the integrations Start a project