I Chose to Be a Builder, Not a CTO

This is my story, not a universal rule. Early on, I realized that the traditional CTO path wasn’t the right fit for me — too many meetings, too much management, and not enough time building. Externally, especially when meeting customers or during sales and bidding, I carried the CTO title because that’s what companies and clients expected to see. But inside, I never truly became a CTO in the traditional sense. I chose to be a builder instead. For me, being a builder means experimenting, creating, and watching the product grow day by day. It’s a personal choice, but one that might inspire others who are also searching for their own balance between leadership titles and the joy of building.

Introduction

Five years ago, I joined a company with nothing in place for engineering. No in-house developers. No DevOps. No architecture. Just an outsourced team that delivered code in black boxes, left no documentation, and handed over systems nobody truly owned.

The company itself operated in government digital transformation, serving large organizations with complex requirements but relying entirely on outsourced delivery. This gap between the company’s ambitions and its technical foundation made the challenge even sharper.

I was hired as the only engineer, tasked not just with writing code but with building the company’s entire technology foundation from the ground up. That meant designing and delivering a suite of more than ten business applications, establishing an integration platform to connect them, and laying the groundwork for a data platform to unify reporting and analytics.

To make that possible, I had to play every role at once: coding, architecting, deploying, interviewing, and gradually assembling a team that would eventually grow to one hundred engineers at its peak. Though I never carried the official title, in reality I was the tech lead from day one.

The path wasn’t glamorous. It was trial and error, late nights staring at logs, debugging obscure bugs, teaching myself what no one else could teach me, and carrying mistakes that became my greatest lessons.

At different points, the company offered me the role of CTO. Many would consider that the dream. I turned it down. Not because I doubted myself, but because I knew what I wanted: I wanted to remain a Builder.

Builders don’t care about titles. Builders care about foundations – writing the first line of code, debugging the weirdest errors, creating technical platforms that others can stand on. Builders aren’t afraid to learn from scratch, to dig through source code, to stitch systems together when no one else will.

This is my story of being a Builder.

The Early Days – Alone in the Wilderness

When I joined, there was nothing. The company’s few apps were outsourced. No internal knowledge. No DevOps. No one to pair with.

I was alone.

The first demo – hacking a calendar

The very first task: create a quick calendar demo for mobile and web to show a potential client. There was no backend, no data input tool. Only urgency: “We need something in three days.”

I hacked a WordPress plugin – exposed APIs, wrote some backend logic, stitched in custom business features. Three days later, the demo was ready. It wasn’t elegant, but it worked. And it won the company its first client in that line of business.

That scrappy plugin became the seed for a proper product later rebuilt in .NET and Vue.js.

The first architectural mistake

My first big decision: architecture. I chose Vue.js frontend, .NET backend, and the shiny new buzzword: microservices.

It was the wrong move.

The team (just me, with some juniors later) spent more time syncing APIs, debugging FE/BE contracts, and arguing “whose bug it is” than solving business problems. Microservices slowed us down, not sped us up.

The lesson came hard and fast: trends don’t equal suitability. Architecture has to match team maturity and business reality.

Recruiting – the lonely battles

Building a team was harder than building code. The company had no brand, no presence in the tech market. Strong candidates didn’t want to join.

I interviewed dozens. Most said no. In the end, I hired juniors. That meant I had to be mentor, trainer, and architect, all while coding full-time. Progress was slow, but the first seeds of a team took root.

No mentor, no AI, no shortcuts

Today, engineers can lean on ChatGPT, Copilot, vibrant communities. Back then, I had Google, StackOverflow, and scattered blogs.

When I wanted to learn data warehouses, I spent nights piecing together dim–fact models from Kaggle datasets. When I needed CI/CD, I wrote my own shell scripts for Linux and Windows.

I made mistakes daily. But I discovered something: walking the wrong path teaches you faster than standing still waiting for guidance.

The wilderness years forged my Builder mindset: walk forward, make mistakes, correct them, and keep moving.

Journey #1 – Integration: My Year With WSO2

By 2022, integration became the bottleneck. Frontends calling backends directly created chaos. APIs were unmanaged, insecure, and inconsistent. We needed an API Gateway and a real integration layer.

I chose WSO2.

Why WSO2?

WSO2 offered a complete suite:

• API Manager (AM) – a powerful gateway.

• Identity Server (IS) – full-featured SSO.

• Enterprise Integrator (EI) and later Micro Integrator (MI) – for orchestration and message flows.

On paper, it had everything. In practice, EI and MI were heavy, difficult to operate, and impossible to trace requests in real time.

When everything collapsed

WSO2 looked fine in dev. But in production clusters, it imploded:

• CPU stuck at 100%.

• Logs filled with cryptic Carbon exceptions.

• Requests disappearing without trace.

The dev team resisted:

• “Why slow everything down with a gateway?”

• “Just let FE call BE directly.”

I knew if I gave in, we’d move faster short-term but remain fragile forever. So I made the hard call: stick with WSO2.

2022 – my WSO2 year

That entire year, my life revolved around WSO2.

By day, I handled projects. By night, I dug into WSO2 source code, rebuilt components, traced logs line by line. I spent months debugging cluster loops, broken sessions, untraceable errors.

It was exhausting, but it forced me to understand how API gateways actually work inside.

The breakthrough

After months of pain, I fixed cluster misconfigurations, stabilized session replication, and tuned load balancing. For the first time, WSO2 ran stable on a multi-node gateway with SSO integration.

The night I saw a clean green dashboard, I felt years older but immensely lighter.

Elsa Workflow – the missing piece

WSO2 AM handled APIs, but EI/MI was too heavy for orchestration. We needed lightweight, real-time tracing of workflows.

I turned to Elsa Workflow – a .NET workflow engine. Elsa gave us what EI/MI couldn’t:

• Visual, step-by-step workflows.

• Real-time traceability.

• Flexibility to extend with code.

I extended Elsa with custom adapters:

• JSON transform adapter for dynamic payloads.

• SQL Server adapter for state storage.

With WSO2 AM as gateway and Elsa as orchestration, we finally had a balanced integration backbone: secure, traceable, and developer-friendly.

Lesson

2022 taught me the hardest truth: architecture is not just code – it is resilience against pressure, the courage to hold a long-term vision when the easy path is to give up.

Journey #2 – Applications: Micro Frontend and the Superapp Dream

Integration solved one bottleneck. Applications created another.

We had dozens of apps: mostly Vue.js, plus several ReactJS modules inherited from outsourcing. Leadership wanted one seamless product.

The dilemma

• Rewrite into one framework → impossible cost.

• Keep separate → fragmented UX.

• Or… merge them somehow.

I chose the third path.

Micro frontend approach

We built each FE app into a JS bundle, rendered them inside a .NET Core MVC shell.

Two problems emerged:

1. Token sharing – Vue and React needed common auth. Solved with WSO2 IS (SSO).

2. Routing conflicts – solved by forcing FE apps to use hash routing.

The midnight victory

The first time a Vue app and a React app ran together, sharing login, inside the same shell, I literally shouted in the empty office at midnight.

From there, we scaled: nearly 20 subapps merged into one superapp. To users, it felt seamless. Internally, it was messy but orchestrated.

Lesson

Good architecture is not about purity. It’s about making things work together.

Journey #3 – Data: From Zero to Supporting the Data Backbone

Not a Data Engineer by trade

I’ve never been a full-time Data Engineer. But when customers demanded enterprise analytics, I had to step into data. Not as the lead DE, but as someone supporting the DE team and bridging gaps.

Learning the basics

To contribute, I learned:

• Dim–fact modeling and star schemas.

• ETL pipeline design – ingestion, transformation, loading.

• Data quality, lineage, partitioning.

I studied Kaggle datasets, blogs, and docs. Not to replace DEs, but to speak their language and support them effectively.

Joining projects as a supporter

In real projects, I helped DEs by:

• Writing ETL jobs under deadline pressure.

• Debugging transformations.

• Bridging between application/integration and data teams.

I wasn’t leading, but I was the extra hands that made a difference.

Acting as the Bridge Engineer

My role became clear: a bridge engineer between app devs, integrators, and DEs.

• Translating requirements between teams.

• Building tools (like GenCode) to save DEs repetitive work.

• Owning problems outside any single team (e.g., PowerBI + SSO).

• Ensuring integration practices aligned with data exposure.

I wasn’t the deepest in any one field, but I was the one who connected the dots.

The 700 “cooked” tables

One customer required 700 cooked tables – transformed datasets for analytics. Each needed CRUD access for validation.

To save the DEs, I built GenCode:

• .NET Core backend.

• React frontend.

• Auto-generated CRUD forms from configs.

Integrated with micro frontend, it delivered hundreds of forms in days. DEs said: “This saves us months!”

Building the data platform together

We assembled a stack:

• NiFi for ingestion.

• Airflow for orchestration.

• Superset or PowerBI for visualization.

When tools failed, I customized modules, patched bugs, tuned configs. I wasn’t a DE, but I kept the platform whole.

The PowerBI nightmare

When a client demanded PowerBI on-premise with OIDC Single Sign-On (SSO), it immediately posed a challenge. Out of the box, PowerBI only supported NTLM and Basic Authentication. OIDC was nowhere in the product roadmap, and community discussions were sparse and inconclusive.

Digging deeper, I discovered that PowerBI allowed a Custom Security Extension (CSE) for authentication. Most examples I found only showed basic database-backed logins—hardly enough for enterprise-grade SSO. Still, it gave me a starting point.

I designed and implemented a Custom Security Extension in ASP.NET that replaced SQL authentication logic with OIDC token validation against WSO2 Identity Server. This meant intercepting login flows, mapping OIDC claims into PowerBI roles, and ensuring tokens refreshed properly in real-time.

After extensive testing, it worked. Users could log into PowerBI seamlessly through WSO2 IS, switching between subsystems with a single identity. What began as a limitation in PowerBI became a production-ready SSO integration—built by adapting the Custom Security Extension far beyond its original use case.

What I gained

By supporting DEs, I built my own foundation:

• I can design and debug ETL flows.

• I understand data marts and lineage.

• I know how to evaluate data quality.

But I remain clear: I am not a DE full-time. My role was to empower DEs, bridge silos, and make the platform end-to-end.

Lesson

Data taught me humility. I wasn’t leading the frontier, but by supporting, I helped the team move faster. And I learned: data is not just tables – it is the nervous system of a business.

Journey #4 – Wearing the CTO Hat Outside, Staying a Builder Inside

There was one more role I eventually had to play – one I never sought, but one the company needed.

As the company grew, we began competing for large enterprise and government projects. These weren’t simple apps. They were national-scale systems, often tied to compliance, regulations, and layers of bureaucracy. To win those bids, someone had to stand at the front – someone who could speak the language of both technology and business.

Stepping into presales

That someone became me.

I joined the presales and bidding process for major deals. I sat in meetings with executives, sometimes even with government agencies, where they wanted to see not just a product, but a vision, a technical foundation, and proof that we could deliver.

I read through laws, decrees, circulars, and regulatory documents line by line. These weren’t written for engineers; they were written in legal and policy language. My job was to translate law into architecture.

• What does this compliance clause mean in terms of database storage?

• How does this reporting requirement translate into a data warehouse model?

• How do we align user privacy obligations with our identity management platform?

I worked with BAs (Business Analysts) to turn vague legal requirements into clear technical specifications. I wrote proposals that bridged the gap between legal language and system architecture.

Wearing the CTO badge in front of customers

In these moments, I became the company’s CTO on the outside.

Customers didn’t want to hear “I’m just a Solution Architect.” They wanted a CTO – someone who could represent the company’s technical credibility at the highest level. And that’s what I became for them: the one who carried the company’s architecture vision into boardrooms, onto bid documents, and in front of government evaluators.

The Board of Directors recognized this. More than once, they told me:

• “You are our CTO in the eyes of customers.”

• “We want you to carry that title.”

I was officially offered the CTO role.

Builder on the inside

But inside the company, I resisted. I knew what came with being a CTO: managing budgets, endless meetings, high-level politics. I didn’t want to stop building.

So I drew a line:

• Externally, I would act as CTO. I would represent the company in presales, negotiations, and bids.

• Internally, I remained a Solution Architect – the first builder, the one shaping platforms, debugging code, and mentoring engineers.

That duality became my balance. Outwardly, I wore the suit. Inwardly, I kept the hoodie.

Why I chose Builder over CTO

For me, Builder isn’t a lower role than CTO. It’s just different. A CTO sets direction. A Builder lays the bricks. I discovered that I find joy not in titles but in foundations – the work that no one else notices until it fails.

Being a Builder means:

• Still debugging API gateways at 2 AM.

• Still writing code generators to save DEs from repetitive work.

• Still stitching systems together when no one else will.

• Still believing in “learning by doing” more than “managing by reporting.”

And that’s why I chose to keep the Builder spirit alive.

Yes, in front of customers and the government, I have been the CTO. But inside, in the real work, I am and always will be a Builder.

Closing – Why This Story Matters

Five years, three journeys, one identity: Builder.

• Integration (2022) – my sleepless year with WSO2, proving that persistence beats collapse.

• Applications – merging Vue, React, .NET into one superapp, showing that pragmatism beats purity.

• Data – supporting DEs, building bridges, proving that humility and learning can build new foundations.

• CTO on the outside, Builder on the inside – balancing the external need for titles with the internal need to keep creating.

I’ve learned that titles may impress customers, but they don’t write code. They don’t fix bugs at 3 AM. They don’t bridge silos or mentor juniors.

Builders do.

That’s why, even when called CTO, I remain first and foremost what I’ve always been: a Builder.