Beyond Tooling: Building Services Is Where Developer Experience Breaks First

Developer experience (DX) is one of the best investments an R&D or engineering organization can make, especially as it grows. It’s not just about tools. It’s about enabling development teams to move faster and safer with less friction.

Source: Unsplash

Over the years, I’ve seen different approaches to the DX in building and maintaining services across teams and organizations. And depending on your stage, size, and needs, your DX in service creation tends to fall into one of these patterns:

1. Velocity Over Standards (Ad-hoc)

Speed First, Structure Later.

There are few (if any) enforced standards. Teams spin up services however they like, and honestly, that’s fine when you’re small.

Early-stage startups need speed. At this stage, spending time building DX tools or funding a dedicated DX team doesn’t make sense. The organization’s goal is to get their product and features out the door before they run out of cash.

Pros

• Maximum flexibility
• Fast to start
• Great for experimentation

Cons

• Inconsistent setups
• Harder to apply org-wide changes
• Drift: Services evolve differently and unpredictably

This works well for small teams, but it starts to break as headcount and service count grow.

2. Cookiecutter Templates

Templating Your Way to Productivity.

Once your team grows, and you have multiple services in production, ad-hoc may no longer be sustainable. Templates are the next step, usually with something like Cookiecutter or a template repository. A typical developer workflow will look like the following:

1. Run a CLI command to create a cookie-cutter template.
2. Enter the service details e.g. service name and description.
3. Run the service. At this point, the service is also ready to deploy.

Templates help enforce consistency and frees up the developers from writing boilerplate code. They can include shared configs, deployment pipelines, logging, monitoring and alerting setups, and the required boilerplate code. This makes it easier to onboard, ship faster, and manage org-wide updates.

Pros

• Faster service creation
• Consistent structure across teams
• Easier org-wide changes and security fixes

Cons

• Easy to create “too many services”
• Teams can still drift from the template
• Templates require maintenance
• One-size-fits-all doesn’t always fit. There will be outliers (e.g., ML systems, payment services, stateful workflows)

Templates are a great fit for medium-sized orgs that want structure without heavy automation.

Here is my cookie-cutter template for building a flask API with a Postgres database.

3. Code Generators

Scaling Consistency with Confidence.

You’re not just bootstrapping—you’re automating. A typical flow will look like the following:

1. Create a base repo. This can also be generated using a cookie-cutter.
2. Define your model (e.g., User).
3. Run your codegen CLI tool.
4. Get a full-featured REST service with /user endpoints, DB access, with logging, metrics, etc.

This is where you go beyond templates. With code generators, you can define a model, an object, or a config and generate an entire service, fully wired up with endpoints, DB access, monitoring, and CI/CD.

Pros

• Strong consistency and velocity
• Easier to roll out cross-cutting changes
• Reduces boilerplate fatigue

Cons

• High upfront cost to build and maintain
• Risk of lock-in or rigidity
• Edge cases might not fit well

Codegen is most common in large orgs with dedicated platform teams and lots of pressure to scale.

When Do You Shift Patterns?

You don’t need to 100% shift to a specific pattern. Organizations usually adapt a combination of these patterns. Some companies stick to ad-hoc for specialized types of services while implementing code generators for their organization-wide generic APIs.

For example, you might not need a codegen or template for your Machine Learning pipelines because you don’t foresee your organization building many of those. However, you might need a combo of cookie-cutter and code generators for your common CRUD services because your product teams need to build this type of service more often.

Lessons and Recommendations

Match your approach to your stage

Fight the urge to over-engineer your tools too way too early. Ad-hoc service creation isn’t going away entirely. There will always be exceptions that don’t fit the template.

Startups? Keep it simple. The wild west is where the pioneers are. Scale-ups? Standardize with templates. Copy-paste doesn’t scale. Enterprises? Automate and codify with templates and generators. Ship faster, safer and more consistently.

Don’t assume a linear path

DX maturity isn’t a ladder you climb once. Sometimes the right move is to go backwards—from codegen to templates, or even from templates to ad hoc for a one-off prototype. That’s okay.

Tooling is not enough

Success depends on buy-in and support:

• Developers need to see the value.
• Teams need to trust the tools.
• Teams need to help improve the tools through feedback and bug reports.
• Someone has to actively own, evangelize and maintain it.
• Leadership has to support the investment

Conclusion

Take a step back. Ask yourself:

• Where’s your team today?
• Are you stuck in a pattern that doesn’t fit anymore?
• Are you making life easier for devs—or adding friction?

Developer experience is never “done.” But the right changes, at the right time, can unlock serious speed and clarity.

If you’ve been through these shifts (or are going through one now), I’d love to hear your story. What worked? What didn’t? What did you learn?