Product Development
The products we build.
Two decades of shipping across every kind of platform we could get our hands on. Internal tools, external products, data systems, dashboards, admin panels, mobile apps, desktop clients, embedded surfaces, and the compound platforms that stitch them together.
All of it guardrailed and carefully thought out. Written for the users who will actually use it, kept honest by the compliance and audit surfaces most teams forget until it is too late, and handed over with the tests, docs, and observability that let someone else pick it up on day one.
Below is a partial list of what has come out the other end. Client work under NDA is not on the list.
Surfaces we build
Whatever your users open. On whatever they open it on.
The surfaces below are the ones we build most often. Each one lives in a different environment, has different constraints, and rewards different discipline. We match the build to the surface, not the other way around.
SaaS platforms
Multi-tenant web platforms with auth, billing, permissions, and audit trail baked in from day one, not bolted on later.
Internal tools and admin panels
Back-office workflows, ops dashboards, and the software your team runs the business on. Usually the highest-leverage build a company will commission.
Web apps
Complex SPAs, dashboards, customer portals, and the interfaces users spend hours inside. Tuned for the browsers your users actually run.
Mobile apps
iOS and Android, native or cross-platform, chosen for what the app actually does rather than what the framework du jour promises.
Desktop apps
Electron and native builds for teams whose work does not belong in a browser tab. Ships with the update path and telemetry a desktop app needs.
Embedded and specialty
Products that live inside hardware, sensor loops, scientific instruments, or bespoke platforms most agencies would not touch. Aerospace and research heritage.
Built for regulated contexts
Products that survive an audit. Not just a demo.
A lot of what we build lives inside regulated environments. Healthcare, regulated fintech, institutional and government research, aerospace, energy. The build has to satisfy the user AND the auditor, and those are different jobs.
That means PII handling and consent surfaces treated as first-class features, not afterthoughts. Access review and permissioning designed with the org chart in mind. Audit trails and data lineage that let your compliance team answer questions before they are asked. Region-locked deployments where residency requires it. Incident-ready observability that produces the evidence your auditor already expects to see.
When we build for a regulated context, we shape the build around your framework (SOC 2, HIPAA, ISO 27001, FedRAMP, or whatever governs you) from the first commit rather than the last. Adding compliance late is a rewrite. Building for it from the start is a discipline.
System types
Different systems. Different disciplines under the hood.
A SaaS platform, a compliance system, and a research data platform look the same from the outside. Under the hood, they are entirely different disciplines. Below are the six we build most often, and what actually goes into each.
Compliance and regulatory
Platforms where the audit trail is the product. Sanctions screening, KYC and investigations, market access tooling, clinical workflows, GxP-relevant systems.
What goes into it
Immutable audit logging, review queues, escalation paths, tiered access, regulator-facing exports, PII isolation, and the kind of change control that survives an inspection.
Stacks we’ve shipped on
PostgreSQL, event sourcing where it earns its keep, standards-compliant identity, region-locked deploys, encrypted storage. Comfortable working around SOC 2, HIPAA, ISO 27001, and FedRAMP surfaces.
AI in the build loop
Faster where it counts. Slow where it should be.
AI sits inside our build loop every day. Scaffolding, first-pass UI, test coverage, refactor mechanics, migration scripts, boilerplate, docstrings, log triage. The mechanical parts of construction move faster because the tooling does the parts that were never the interesting bit.
The parts that decide whether a system holds up in two years still get built slowly and on purpose. Architectural calls. The security surface. Compliance-critical paths. Anything that touches PII, production, or a regulated data flow gets human judgment before it lands. Model choice honours data residency. No client PII enters vendor models. Local and on-prem model options are on the table when the regime requires them.
What we build with AI is portable. Custom Claude skills tuned to your codebase, agent loops in your CI, testing harnesses shaped around your patterns. When the engagement ends, all of it stays in your repo, running the way we ran it. Your audit team can trace what a model wrote back to the prompt that produced it.
Free tools
Two honest reads before you build.
Product team or feature factory, and can the data underneath carry the AI on the roadmap? Both scored free in your browser.
Start honestly
Tell us what you want to build.
A first conversation is free. We will listen to what you have, tell you honestly whether we are the right team, and if we are, help you scope the shape of the build before you commit to anything.
Talk about the build