From an Idea to an Acquisition: What Building a Startup Taught Me

There was no playbook

In 2007 I co-founded a company with an idea and not much else. There was no engineering organization to join, no platform to inherit, no team waiting for direction, and no playbook for what came next. We had to figure most of it out as we went.

The company built a global communications platform: VoIP and cloud telecom services for underserved and underbanked communities, including many immigrants who were often poorly served by traditional financial systems. Some customers used the service directly. Others reached it through local businesses that resold it in their own communities and ran on our hosted platform.

I was a co-founder and the CTO. The platform grew past 400,000 users across South America, Asia and Africa, handled millions of dollars in transactions, and grew revenue to multimillion-dollar levels. In 2013 the company was acquired. I stayed on board after the deal closed, and my part of the story ran until 2024.

I came into it from networks, not startups. I’d kept a nationwide carrier network running and then run operations for a voice service. I knew a lot about how networks fail. I knew much less about building a company, hiring a team, or deciding which problems were worth solving first.

From the outside, the story fits on one line: idea, growth, acquisition. From the inside it was a long run of decisions made with incomplete information, some of them wrong, and a slow change in what my job actually was. Those are the parts I want to write down.

0→1: Building something from nothing

What does 0→1 mean in startup engineering?

In startup engineering, 0→1 is the stage where nothing exists yet: no product, no customers and no proof that anyone wants what you’re building. The job is to find a real problem, ship the smallest thing that solves it, and make good decisions with incomplete information.

At that stage, titles don’t mean much. I was the CTO on paper. In practice, in a given week I might be doing product management, writing the web application, building the voice network, racking and cabling servers in the data center, working on marketing and SEO, and answering a customer who couldn’t connect.

We built everything from scratch, from racking servers and building the network to writing the software, and we were bringing in revenue in less than four months.

All of this is happening at once, and all of it is yours:

• Product
• Engineering
• Architecture
• Infrastructure
• Customers
• Operations
• Production problems
• Business decisions
• Hiring
• Priorities

Nobody hands you a priority list. You decide which of those gets your attention today, knowing the rest will still be there tomorrow.

Start with the problem, not the architecture

My instinct as an engineer was to start with the system: how it should be structured, how it would scale, what it should be built on. Those questions matter. They just aren’t the first questions. Early on, I didn’t know which parts of the product would matter, which customers would stay, or what they’d actually use it for. An architecture designed before you know those things is mostly a guess with a diagram attached.

The more useful question was simpler: what problem does this person have, and what’s the smallest thing we can build that actually solves it?

Fast, or able to change?

Every early decision sits on a tension between building quickly and building something that can evolve. Build too slowly and you run out of money or time before you learn anything. Build carelessly and the thing you learned from becomes the thing you can’t change.

What is the simplest architecture that solves today’s problem without making tomorrow unnecessarily difficult?

I didn’t always answer that well. Some things I built more elaborately than the stage called for, and some I built so quickly that we were paying for them long after. But asking the question every time was better than defaulting to either extreme.

The first data center is a good example of when it worked. We planned it deliberately and kept the tiers clean: web, application and data as separate layers. That wasn’t because we expected to leave. Clean layers were cheap to build and easy to reason about. Later, when we did move to cloud regions on three continents, those tiers moved as units. The care we took early is what made the later change possible.

Building for people the system wasn’t designed for

Our customers changed how I think about product engineering more than any architecture decision did.

Many of them were immigrants. Many were underbanked. A lot of them dealt with money, identity and technology differently from the people who usually design software, me included. It’s easy, as an engineer, to assume every user has a credit card, a bank account, a stable address, a name that fits neatly into first-name and last-name fields, fluent English, and a fast connection on a recent device. None of those were safe assumptions for us.

Assumptions like that are rarely decided on purpose. They creep into a signup form, a payment flow, a fraud rule or a support script because that’s how the people building it live. Then they quietly turn real customers away, and nobody notices, because the customers who were turned away aren’t in the data.

The reseller channel added a second kind of customer: businesses that sold our service in their own communities and ran on our hosted platform. They needed tools to run their own business, and they needed the platform to keep working for customers who trusted them, not us. Building for both at once taught me that “the user” is rarely one person.

Build for the person using the system, not for the engineers building it.

That sounds obvious. In practice it means questioning defaults you didn’t know you had, and paying more attention to what customers actually do than to what you assumed they would do.

When software becomes a business

There’s a point where software stops being a project and becomes something people depend on. Nobody announces it. You notice because the questions change. Before that point I mostly asked whether something worked. After it, the questions looked like this:

Reliability

What happens when this fails, and who notices first?

Security

Who could misuse this, and what would it cost the customer?

Data integrity

Can we prove every transaction is right?

Deployments

Can we ship this without taking anything down?

Monitoring

Will we know before the customer tells us?

Performance

Does it hold up for a user on the other side of an ocean?

Operations

Who handles it at night, and do they have what they need?

Customer support

Can support explain what happened, in the customer’s terms?

Production incidents

When it breaks, do we learn something, or just fix it?

Reliability becomes part of the product. When software handles real transactions for people who may not have much margin, a bug isn’t an engineering inconvenience. A failed payment or a wrong balance is someone’s money. A dropped call is a conversation that didn’t happen.

Voice made that sharper. Real-time traffic can’t hide behind a cache, and our users were spread across South America, Asia and Africa. Every session from the far side of an ocean paid for the distance in latency and call quality. Users feel geography before they notice any new feature.

That pushed one of the biggest technical decisions we made: leaving the single data center we’d planned so carefully, and running the full application in cloud regions on three continents, with each user routed to the nearest one. A small engineering team that also owned operations did it with no downtime window, because users were active in every time zone. I’ve written up that move from one data center to three continents as a case study.

My years in network operations helped here. Most outages aren’t dramatic. They’re a full disk, an expired certificate, a config change nobody reviewed, or a dependency that got slow. What I had to learn was how to build that knowledge into the system and the team, instead of keeping it in my head.

1→10: Scaling more than software

What changes when a startup goes from 0→1 to 1→10?

At 0→1 the job is to solve the problem. At 1→10 the job is to build a team and a system that can solve problems repeatedly, without a founder in every decision. Processes, ownership, deployments, architecture and technical debt all have to become deliberate.

The things that got us to our first customers started to break as we grew, one at a time and usually under load.

• Early processes stopped working. What a small team could coordinate by talking had to be written down once the team outgrew a single conversation.
• Knowledge couldn’t stay in people’s heads, including mine. Every system only one person understood was an outage waiting for that person’s vacation.
• Deployments had to become repeatable. A release that depended on someone remembering the right steps would eventually go wrong.
• Ownership had to become clear. “Everyone owns it” turned out to mean nobody did.
• The architecture had to evolve while the business kept running on it.
• Technical debt needed managing, not just accumulating.
• Communication had to scale, between engineers and between engineering and everyone else.

Underneath all of that, my job changed.

0→1

Solve the problem.

1→10

Build a team and a system capable of repeatedly solving problems.

The second job is harder, and much less visible. When you solve a problem yourself, you can point at it. When you build a team that solves problems, the evidence is that things keep working when you aren’t in the room.

Engineering organizations are systems too

As the team grew, more of my time went to things that never show up in the codebase: team structure, hiring, mentorship, ownership, how architecture decisions got made, documentation, code review, deployment processes, engineering standards, communication, and how engineering worked with the rest of the company.

I treated those as overhead for longer than I should have. An engineering organization is a system too, with the same properties as the software it builds.

A strong engineering leader has to be able to debug the organization the same way they’d debug the software: look at the symptoms, form a hypothesis, find the real constraint, change one thing, and watch what happens. When delivery slows down, the cause is rarely where it first appears. It’s often a review queue, an unclear owner, or a test suite nobody trusts. I’ve written about reading one of those signals in what sprint carryover is actually telling a team.

Decisions are part of the system too. The ones that outlive the meeting where they were made need to be written down with the options and the tradeoff, or the next person to touch that part of the system has to rediscover the reasoning from scratch.

From technical founder to engineering leader

How does a technical founder become an engineering leader?

A technical founder becomes an engineering leader by moving from solving problems personally to making sure other people can solve them well: giving engineers the problem, the context, the constraints and real ownership, and getting out of the way of the decisions they can make.

This was the hardest transition for me, and I didn’t make it cleanly.

When you built the first version of something, you know where everything is. You can often fix a problem faster than you can explain it. That’s true, and it’s a trap. Every time I solved something myself because it was quicker, the team learned that hard problems came back to me. I became the bottleneck I would have flagged in anyone else’s system.

Being capable of solving a problem doesn’t mean the leader should be the one solving it. The change showed up in how I handed work over:

Before

“Here’s exactly how I would implement this.”

After

“Here’s the problem, the context, the constraints, and why it matters. What do you think?”

The first version gets a task done. The second gets a better answer more often than I expected, because the engineer closest to the work often sees something I don’t. It also builds someone who can handle the next problem without me.

Context is the part leaders skip. An engineer who knows why something matters, what it connects to and what we can’t compromise on will make good decisions I wouldn’t have thought to ask for. An engineer who only has the task will do exactly the task.

What I wanted was an organization that makes good decisions without the leader becoming the bottleneck. That idea became the center of how I mentor engineers: every step moves a decision from me to them.

How should startups think about technical debt?

Technical debt isn’t automatically bad. Some comes from poor engineering, and some comes from rational business decisions made with limited time, money, people or information. Treat it as an investment decision: pay down the debt that costs you speed, reliability or security, and leave the rest.

A startup with no technical debt probably shipped too slowly. Some of our debt is what kept us going: things built quickly because a customer needed them now, or because we couldn’t yet afford to build them properly. Most of those were the right calls at the time.

Some of our debt was just mistakes: shortcuts that weren’t buying anything, or designs that weren’t thought through. That kind is worth being honest about, because pretending all debt was strategic is how a team stops learning from it.

So I stopped asking whether we had technical debt. We always did. The better questions were:

1. What is it costing us?
2. What risk does it create?
3. Is it slowing development?
4. Is it affecting reliability?
5. Is it affecting security?
6. What is the opportunity cost of fixing it now?

The last question is the one engineers tend to skip. Every week spent on a rewrite is a week not spent on something a customer asked for. Sometimes the rewrite is still right. But it has to compete with everything else on the same terms: what it costs, what it returns, and what happens if we wait.

Framed that way, technical debt stops being an argument between engineers who want to clean things up and a business that wants features. It becomes an investment decision both sides can reason about. I still run it that way: capacity set aside every cycle, spent where debt blocks the roadmap.

The acquisition

In 2013, the company was acquired.

I’m proud of that. It was real validation that what we built had value to someone else, and it mattered to the people who had bet on us. But I’d be telling the story wrong if I made it sound like the destination we were always heading for. For most of those years the acquisition wasn’t a plan. It was one possible outcome among many, and several of the others were much worse.

From the outside, startup stories tend to look like the first line below. From the inside, they look like the second.

The second line is closer to how it felt. Most days the outcome was far away, and the next problem was right in front of us.

I stayed on board after the deal closed. An acquisition changes who owns a company. It doesn’t change what customers need from the platform the next morning.

The deal mattered. What I learned getting there, and after it, has mattered more.

What those years changed

I started out thinking like an engineer. The questions I cared about were technical: is it correct, is it fast, is it well designed?

Over time I learned to think about the larger system the software lives inside:

• Technology
• People
• Customers
• Operations
• Money
• Risk
• Timing
• Execution

Any one of those can sink a company that gets the others right. Three ideas from those years have stayed with me more than any technical lesson:

1. A technically correct decision can still be the wrong business decision.
2. A perfectly architected system nobody needs has zero value.
3. Engineering leadership is about repeatedly turning difficult problems into valuable outcomes.

The first took me longest to accept. Being right about the technology and being right about the business are separate questions, and the second one usually decides what happens.

Why I still build

Since then I’ve led technology for a media publishing platform, and today I lead architecture and delivery work for government, startup and founder clients through Yippify. I still write software. I build my own products too: VeloWise for delivery analytics, SurgeIQ for cycling stats and workouts, Useful Little Tools for everyday calculators, and FedPath for small businesses chasing federal contracts.

Lately most of my experimenting is AI engineering: working with LLMs, retrieval-augmented generation (RAG), agents and the Model Context Protocol (MCP), alongside cloud platforms, modern application architecture and developer tooling.

I don’t do it to be the team’s primary coder. An engineering executive doesn’t need to personally implement every production feature, and a leader who tries usually becomes the bottleneck I described above.

I stay hands-on for a narrower reason: to understand new technology well enough to judge it. Whether it’s useful or just new, what its risks are, what it will cost to run and own, and which questions to ask the team that will build with it. You can’t evaluate an AI feature’s failure modes from a slide, and some of the most useful conclusions are about where not to use it.

It’s the same point I made in You Don’t Need to Remember Everything to Be a Good Software Engineer: the job is judgment, and judgment needs enough first-hand understanding to be worth anything. You can see what I’m building now on the projects page.

What I’d tell someone starting today

If you’re building something from nothing, this is what I’d tell you, mostly because I learned it the slow way:

1. Find a real problem. Ideally one you can describe without mentioning your solution.
2. Talk to customers, before you build and constantly after.
3. Build the smallest useful version.
4. Get it into people’s hands.
5. Observe what they actually do, not what they say they’ll do.
6. Learn.
7. Change it.
8. Repeat.

As usage grows, invest deliberately in architecture, reliability, security, automation, people and process. Not all at once, and not before you need them. Don’t prematurely optimize for a scale you may never reach.

But learn to recognize when yesterday’s solution is becoming tomorrow’s bottleneck. It rarely announces itself. It shows up as slower releases, more incidents, more questions routed to one person, and a team that’s busier without shipping more. That’s when to invest.

Short answers