Case study / Internal developer platform
Business logic above.
Platform machinery below.
Ground was the Rust application framework and CLI within Volt’s broader internal developer platform effort.
- Problem
- New services meant assembling common application behavior and infrastructure from scratch.
- My contribution
- As Head of Platform, I personally designed and built Ground’s framework, CLI, generators, and shared test fixtures.
- What changed
- Services gained versioned shared capabilities, consistent conventions, and a connected starting point for implementation.
- Outcome
- Used across the engineering team for all new services. Faster, more maintainable development; a qualitative result rather than a measured speedup.
- 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
Integration tests.
Real, isolated dependencies.
Integration tests using the shared application fixture received fresh PostgreSQL, Redis, and Faktory containers. The application router ran in the test process and handled requests against those dependencies.
Fig. 02 / Conceptual test setup
Integration test / Shared application fixture
Starts its own services
Application router runs in-process
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.
Adoption meant engineers used the same versioned framework and CLI for new services. Shared conventions, generated structure, and fixtures traveled with the code rather than depending on someone explaining the starting point each time.