Building in public: what we learned launching an 8-discipline tech firm

The conventional advice for a new services firm is to niche down: pick one thing, get famous for it, expand later. We heard that advice, understood it, and chose to ignore it — on purpose. Centr8 launched with eight disciplines wired together from day one, because the businesses we wanted to serve don't experience their problems one discipline at a time. They need software and the cloud it runs on, the data underneath it, the security around it, and the marketing to put it in front of customers.

Going wide is a harder way to start. It stretches positioning, complicates hiring, and gives prospects more ways to misunderstand you. This is an honest account of the bets we made and the ones we'd make differently. Whether you're launching a firm or just trying to scope a vendor, the trade-offs translate.

Why we built wide instead of deep

The trigger was a pattern we kept seeing: a company hires a web shop, then a separate cloud consultant, then a security auditor, then a marketing agency — and spends most of its leadership time as a translation layer between vendors who don't talk to each other. The handoffs are where projects rot. A feature ships, but nobody owns whether it's observable, compliant, or actually driving signups.

So the "8" in Centr8 isn't a logo flourish — it maps to the eight things a modern company genuinely needs from one accountable team:

• AI & Machine Learning — models, automation, and LLM features that earn their keep
• Web & Mobile App Development — the product itself, on every screen
• Data & Analytics — pipelines and dashboards that turn activity into decisions
• Cloud & DevOps — the infrastructure, CI/CD, and reliability behind it
• IT Consulting — the strategy that keeps the build pointed at the business
• Security & Compliance — audits and controls, designed in rather than bolted on
• Digital Marketing — SEO, paid, and CRO so the work gets seen
• Maintenance & Managed Support — the unglamorous part that keeps it all alive

Centralize them, and the client stops managing vendors and starts shipping outcomes. That's the whole thesis — and it only works if the disciplines are actually one team, not eight logos on a slide.

The hardest part wasn't the work — it was the positioning

We assumed the engineering breadth would be the challenge. It wasn't. The real difficulty was explaining ourselves without sounding like a generalist that does everything and masters nothing. "We do eight things" reads as a red flag to a careful buyer, and rightly so.

What fixed it was reframing the offer around the seam between disciplines rather than the disciplines themselves. People don't pay a premium for a cloud setup; they pay for a product that ships secure, observable, and ready to scale without three separate kickoff calls. A few rules we landed on:

• Lead with the outcome a client wants ("launch a product," "become data-driven"), then show which pillars combine to deliver it — not the org chart.
• Sell one contract, one team, one point of accountability — the integration is the value proposition.
• Be willing to say no. If a prospect only needs one narrow thing a specialist does better, telling them so builds more trust than winning the line item.

Hiring for range without losing depth

Eight disciplines could imply eight shallow teams. We refused that. The constraint we set was that senior people stay close to the work — experienced engineers on delivery, not a polished pitch followed by a junior handoff. Breadth at the firm level has to be built from depth at the person level, or the whole premise collapses.

Concretely, that shaped how we staff:

• We hire T-shaped people — deep in one discipline, fluent enough in the adjacent two to hand off cleanly without a translation layer.
• We keep teams small and accountable, so the person who designed a thing is usually still around when it needs support.
• We treat "boring" disciplines — maintenance, compliance, observability — as first-class, because they're where breadth quietly pays off and where most firms get lazy.

What we'd tell another founder building wide

Building in public means admitting the version that almost didn't work. Early on we tried to present all eight pillars with equal weight everywhere, and it diluted everything — prospects couldn't tell what we were for. The fix was to anchor each conversation in a single outcome and let the breadth show up as proof, not as the pitch. If you're considering a wide start, our short list:

• Earn the right to be broad by being deep first. Breadth without senior depth is just a longer list of things to do badly.
• Make accountability the product. Anyone can assemble vendors; the rare thing is one team that owns the result end to end.
• Default to transparency. Shared boards, honest updates, and clear scope do more to win wide engagements than any capabilities deck.

Where this leaves us

Building wide is not for everyone, and we won't pretend the narrow path is wrong — for many firms it's exactly right. But for the kind of client who's tired of stitching vendors together, a single team that can reason across strategy, build, security, and growth is worth the harder start. If you're weighing how to structure a build like this — one team or several, in-house or partnered — that decision is exactly the kind of thing our IT Consulting work exists to help you get right before a line of code is written.