One engineer, the whole lifecycle
A system like BarakoCMS, the event-sourced CMS you can sign into at playground.baryo.dev/barakocms, normally needs a small team: an architect, a backend engineer, a front-end engineer, a database person, someone on DevOps, someone on QA, and someone to keep the hand-offs from dropping work on the floor.
I have done all of those jobs, in production, for most of my career. Not because one person is the right way to build everything, but because doing the whole thing is how I learned where the seams are. Here is what each part looks like when it all lands on one desk.
Design
Figma to a responsive front end in Vue, React, or Blazor. The trick is building a design system that still holds up once real content, and real edge cases, hit it.
Build
REST APIs, event-driven services, event sourcing, plugin architectures. Usually in C#, TypeScript, or Go, picking whichever one suits the job rather than forcing the job to suit the language.
Data
Schema design that is still workable in year two: PostgreSQL, event stores, migrations, optimistic concurrency, and backups I have actually restored. An untested backup is not a backup.
Test
Unit tests with coverage gates, Cypress for end-to-end, JMeter for load, OWASP ZAP for security, all running in CI so nothing depends on someone remembering to check.
Ship
Docker, GitHub Actions, zero-downtime deploys. On AWS and Azure over the years, and lately on cheap VMs I drive with my own tool, BaryoVM.
Operate
Structured logs, telemetry, and the 3am debugging on systems people use every day. This is the part that never shows up in a screenshot, and it is usually the part that decides whether the software was any good.
The parts that were never greenfield
Adding a library to a fresh repo is easy. The work that taught me the most was the opposite: taking a twenty-year-old system forward without breaking the thing that pays the bills. AS400 green screens and RPG, VB6, old .NET, moved ahead a piece at a time while they stayed in production.
That is what most of my client work has looked like. There are more of those stories, without the names, in The work you can't see on GitHub.
If this is close to something you are building, email me.