Long-Term Engagements Are Different
Most development contracts are short. The CCS engagement was different: 1,921 billed hours over an extended period, totaling $77,240. This kind of relationship requires more than technical skill, it requires the discipline to make decisions that scale over time, write code the next engineer can maintain, and communicate as a trusted partner rather than a ticket-taker.
The code you write in hour 100 has to work with the code you wrote in hour 1. That changes how you think about every architectural decision.
Why Go for the Backend
When we started the CCS engagement, the choice was between Node.js, Python, and Go. We recommended Go for three reasons that mattered for a long-running project:
- Concurrency model: goroutines and channels make CCS's data pipeline work clean rather than callback-heavy
- Performance: Go's static binary starts fast and runs fast, no JVM warmup, no GC pauses that spike latency at inopportune moments
- Type safety at compile time: a 1,900-hour project needs the compiler catching errors, not runtime panics in production at 2 AM
The static typing also meant that engineers who joined the project later could read unfamiliar code and trust what the types told them, no runtime surprises.
Why React for the Frontend
The CCS frontend is data-dense: tables, charts, and form-heavy workflows with complex validation rules. We built it with:
- React Query for server state, cache invalidation across complex related data sets, background refetching, and loading states without boilerplate
- React Hook Form + Zod for validation, the Zod schemas were shared with Go backend DTOs via OpenAPI code generation, so client and server validation stayed in sync automatically
- TanStack Table for the high-density data views, virtualized rows for performance when displaying thousands of records
Engineering Practices That Made 1,921 Hours Sustainable
Shared type contracts via OpenAPI
We defined the API contract in OpenAPI spec, then generated TypeScript types for the frontend and Go structs for the backend from the same file. Any breaking API change fails the codegen step, the compiler finds it before a developer does. This single practice prevented entire categories of integration bugs.
Incremental delivery every two weeks
Every sprint ended with a deployable build. No "big bang" releases. The client saw working software at every checkpoint, which meant course corrections happened when they were cheap, not after six months of work had been built on a wrong assumption.
Test coverage on business logic, not implementation details
We tested the data pipeline and calculation logic extensively. We didn't test React component render output or mock the database, those tests break when you refactor and don't actually verify the system works. Integration tests against a real PostgreSQL instance caught the bugs that mattered.
What $77K of Software Looks Like
It looks like a production system that still works three years later. Readable code. Documented architectural decisions. Tests on the critical paths. An architecture that let the client hire a second developer without a six-week onboarding ramp. That's the real deliverable, not just working software, but software that stays working.