Case study / Internal developer platform
Business logic above.
Platform machinery below.
At Volt Labs, I designed and built Ground, a Rust application framework that moved repeatable technical concerns into the platform. New services previously required engineers to rebuild common application plumbing. Ground was used across the engineering team for all new services, resulting in faster, more maintainable development.
- Organization
- Volt Labs / Enterprise messaging
- My role
- Head of Platform
- Focus
- Architecture, framework & developer tooling
01 / The problem
A new service meant rebuilding the starting point.
Volt used a polyglot stack, choosing technologies to fit the problem. Rust was already part of that environment.
Before Ground, functionality added to the monolith had access to only a few shared capabilities, such as JWT authentication. An independent service meant establishing its own application stack and supporting infrastructure. There was no standardized starting point for the concerns those services shared.
Engineers became capable at solving this technical machinery, but that work competed with time spent learning the SMS business domain. Developer attention was repeatedly pulled toward infrastructure and framework problems instead of the problems the business actually needed them to solve.
02 / The responsibility boundary
Give business logic a clear owner.
Fig. 01 / Conceptual responsibility model
Application developer owns
Business logic
Domain knowledge · Application behavior
Platform boundary
Ground owns
Repeatable application plumbing
Shared capabilities · Conventions · Test environments
Application developers should own business logic. The platform should take on as much of the repeatable technical work beneath it as is practical.
That boundary gives the platform team somewhere to encode organizational knowledge: defaults, conventions, and workflows that application engineers would otherwise rediscover for each service.
03 / Encoding the boundary
Ground: a place to start.
I designed and built Ground to provide an established application foundation within Volt’s Rust environment.
The framework and application CLI were distributed through an internal registry. Developers could use the shared foundation as versioned packages.
Common application behavior
Authentication, validation, error handling, pagination, and serialization gave recurring application concerns a shared framework treatment, rather than asking every service to assemble its own starting point.
Data and background work
Connection pooling and migrations supported data access. Generated applications included Faktory background-job integration, with workers sharing application configuration and telemetry setup.
A repeatable development experience
Scaffolding, environment-specific configuration, logging, testing, and fixtures extended that foundation beyond request handling into everyday development.
Generate a component and its surrounding conventions.
For example, a developer could scaffold an illustrative widget component from a Ground application:
cargo ground generate scaffold widget
- Create the related files. The scaffold path rendered a controller, model, repository, service, SQL queries, migration, tests, and fixture templates.
- Wire in the service. Rust syntax-tree manipulation added the service import, field, and initialization to the application’s service collection.
- Build the behavior. Developers started with a connected structure to adapt to the domain, reducing manual wiring and repeated decisions.
04 / Testing architecture
Real dependencies.
A fresh environment for every test.
Each test ran against its own services. The generated test helpers started PostgreSQL, Redis, and Faktory in Docker containers for that test, so developers tested against the real thing without sharing state between tests.
Fig. 02 / Conceptual test setup
Each test
Starts its own services
Runs against them, then moves on
Its own Docker containers
- PostgreSQL
- Redis
- Faktory
Fixtures and common setup gave developers a starting point for exercising application behavior against real supporting services, without rebuilding that setup for each new component.
05 / Decisions & constraints
A useful platform still has a cost.
Why Rust made sense here.
Volt already used Rust. The existing Rust framework relied heavily on macros and could be difficult to debug. Ground was an attempt to keep Rust’s runtime performance, memory safety, and type safety while improving the application development experience.
The costs remained real: a learning curve, the maturity of the ecosystem at the time, and productivity challenges when framework support was insufficient. A stronger application foundation was a way to address some of that friction.
What was worth building now?
Engineering time was finite. Every investment in the platform competed with immediate business requirements. Technical feasibility alone could not decide what belonged in Ground.
The architectural question was whether a recurring concern justified a shared implementation now. Platform capability, developer experience, business priority, and available engineering time all had to be weighed together.
06 / Adoption & consequences
A shared foundation the whole team used.
I personally designed and built Ground. It was used across the engineering team for all new services. Development became faster and more maintainable.
Shared conventions, generators, and test helpers made the platform boundary concrete in everyday work. Ground successfully hid repetitive technical machinery while preserving a useful mental model.