Tool freedom kills IT’s delivery speed

Standardization beats the tool chaos that could be slowing down IT’s work by 50%.

Oct 17, 2025

This is “Effective Delivery” — a bi-weekly newsletter from The Software House about improving software delivery through smarter IT team organization.

It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.

TL;DR

Without standardization, teams waste weeks debating tools and building duplicate systems
Standardize project setup templates first to eliminate repetitive configuration
There are 8 areas IT managers can standardize
Look for standards created by engineers that could help the entire team
We cut project setup from 3 days to 30 minutes thanks to our boilerplates

1. Endless tool choices slow down teams

2. What to standardize (in order)

3. How to introduce standards

Hey! Adam here again.

Giving developers complete freedom to choose their tools doubles (or triples) delivery time.

This can manifest in many ways:

Teams can waste weeks debating whether to use React, Vue, or Angular when they could be building features,
Developer might insist on testing their favorite AI coding assistant instead of writing code,
We once worked with a corporate client whose 20+ teams had to coordinate just to update a simple logo across their websites.

The difference in tools and tool know-how among developers is what’s causing the slowdown.

It’s time to bring back the monarchy to deal with this chaos! 😄

Today, you’ll learn what IT should standardize, and in which order, based on our own history.

Endless tool choices slow down teams

The wider your tool selection becomes, the lower your overall efficiency is:

Each new gadget requires learning time,
Developers lose work efficiency if they keep switching tools,
Too many tools limit the feature team’s chance to master them.

So, if you narrow down the options, engineers should spend more time on delivering features.

That’s why standardization is good.

Our developers used to choose their favorite AI tool.
But the freedom to choose Copilot, Cursor, Windsurf, or some Devin created chaos.
We wasted time on explaining the differences between them.
We now have 2 approved options only.
GitHub Copilot or Cursor.
Each project uses just one of them.

Some managers falsely believe standardization means forcing one solution onto everyone.

Real standardization provides a spectrum of pre-vetted options and eliminates endless evaluation cycles.

At TSH, our teams build frontends in React + Next.js (internal/external) or Vue (only external per client’s request).

No Angular. It wasn’t a fit.

Most of our engineers maxed out AWS expertise for the same reason.

Unblock Delivery in 2-4 Weeks

Did you know? My engineers at TSH help organizations fix delivery blockers in 2 sprints max. Results are guaranteed.

Learn how they help

What to standardize (in order)

1. Project starter templates (week 1)

Your platform team or a senior full-stack developer should create these templates.

Companies create new features or services more frequently than they realize.

The manual setup of such burns precious time.

Our three starters (React Starter, Express Boilerplate, and Serverless Boilerplate) save us days of work on each commercial project.

They include CI/CD pipelines, a standardized log format, and authentication that works out of the box.

Find them on our GitHub!

2. Authentication (week 2-4)

Your architect or technical lead should standardize authentication patterns.

Authentication touches every application you’ll build.

We built components that use Azure AD once and apply them everywhere.

In the past, we coded a tailored user and authorization service for each app.
To get off the hamster wheel, we switched to Azure AD internally.
In commercial projects, we suggest Fusion Auth, Auth0, or Keycloak.

3. Design system (month 1-2)

Your frontend lead and UX designers should build the design system.

All internal applications at TSH use the same components.

We based our design system on ShadCN with our branding.

Instead of asking how a table should look, our engineers ask if we have that component and build for everyone if we don’t.

4. Data fetching (month 2-3)

Your backend architect should define data fetching standards.

Define exact specifications for how tables request data from backends.

Otherwise, developers will waste time working with different standards.

One engineer might use ?sort=name:asc, while another will prefer ?orderBy=name&direction=ascending.

We created a “data grid” standard.
It’s built into our design system and the backend boilerplates.
Every endpoint that serves table data follows the same query parameter structure, returns the same pagination metadata, and handles sorting and filtering identically.

5. CI/CD automation (month 3-4)

Your DevOps engineer or platform team should automate pipelines.

IT teams shouldn’t spend time on setting up CI/CD.

When we create a new project with our starter, it rolls out a preset for data and log collection.

It also includes configuration for GitHub actions, Gitlab CI, and Bitbucket Pipelines which cover:

unit and integration tests
E2E tests
static code analysis
security scanning

Your engineers should know that deployment always looks the same across all projects.

6. AI assistants (month 3-4)

An Engineering Manager or the CTO should evaluate and select AI coding tools.

We settled on Copilot or Cursor.

We track success through token usage.

Over the months, it went from near-zero to 45% for 220 of our engineers.

70% is our new goal.

7. Core technologies (month 4-5)

The CTO should define the approved technology stack with the architects.

Shrink the stack to see more developers who mastered it.

A choice limited to 1 per area is best for speeding up delivery.

Here’s how we did it at The Software House

Please note we need multiple choices to work on software projects across industries

• Frontend and backend

1 to 2 frameworks (like 1 for spa and 2 for ssr) and 1-2 languages depending on the use case.

We primarily use React/Next.js and PHP/node.

• Full-stack

Node and React.

• Databases

1 database per data type.

We use PostgreSQL for relational, MongoDB for documents, and Redis for caching.

• CMS

1 out of 3 options, depending on the media hosted and accessibility for editors.

We approved Storyblok, Payload, and Contentful.

• Authentication

Fusion Auth, Auth0, or Keycloak.

• AI and data engineering

Node/Python.

• Cloud

We use AWS in 90% of projects but also specialize in Azure and GPC.

How to introduce standards

If a feature team has to solve the same issue twice, mark it for standardization.

An architect can transform the feature team’s solution into a standardized package.

Then, the Team Lead / Engineering Manager can see if the new standard:

is being discussed during dailies,
is a part of the code seen during reviews,
is reflected by any usage metrics connected to it,
is used by new engineers in their first weeks (what we do).

And do watch out for engineers promoting an alternative solution that’s “more convenient”.

They might not get that you’re trying to save time.

Next time

Personal responsibility.

It would surely help engineers stick to the agreed standards!

EDN#10 will explain how managers can motivate team members to take ownership.

My friend Jakub Pawełek (our Delivery Manager) will take over.

Thank you for your time today 🙏🏻

🟣 Substacks we read

Ever feel like your hard work goes unnoticed?

You’re not alone. That’s why thousands of engineering leaders subscribe to Thriving in Engineering for practical guides that turn invisible effort into visible impact.

Written by 25+ year industry veteran Alex Ponomarev.

👉 Start with this piece: