Building Startups: What I’ve Learned Turning Ideas Into Working Products

Rarely just a developer

Over the years I have worked with a fair number of startups. Some were building mobile applications. Others were building fitness platforms, telecom services, real estate software or virtual tour technology. Different industries, different stacks, different business models, and one thing in common: each had to turn an idea into a working product with limited time, limited money and a list of wants longer than either.

When you work with a startup you are rarely only the developer. You might be helping the founder decide what to build, choosing the stack, designing the architecture, standing up the infrastructure, writing the code, troubleshooting production, and working out how to deliver all of it without spending money the company does not have. Some days you do several of those before lunch. I have lived that as a founder of my own company and as the person helping other people build theirs, and each engagement taught me something the last one had not.

Startups need more than someone who can write code. They need someone who can help them make the right technical decisions for the stage their business is in: what to build now and what can wait, which stack the team can actually own, how simple the architecture can be, and what it will cost to run.

A hybrid mobile app on a LAMP backend

One startup needed a mobile application on both iOS and Android, and I served as its interim head of engineering. We built a hybrid app, one codebase rendering on both platforms, backed by a LAMP stack, Linux, Apache, MySQL and PHP, running on AWS with REST APIs between them.

Hybrid was the important decision. Two native apps would have meant two codebases and two sets of skills to hire and keep, and for a startup that maintenance cost is not a rounding error. A hybrid app shared most of the code across both platforms, at a price in native capability, performance and the occasional compatibility surprise that we accepted with our eyes open. The backend was deliberately familiar. LAMP was not fashionable, and it was a stack the team already knew for building APIs and managing data, which meant the surprises were in the product rather than the plumbing. AWS gave us infrastructure without buying servers, which I had done for my own company and did not wish on anyone running on a seed round.

The question that mattered was whether we could build something useful, maintainable and affordable for that business at that moment, and the answer shaped every technical choice. For an early-stage company, the technology that fits the product, the team and the budget beats the newest one.

Staying on after selling my own company

The startup experience that taught me most was my own. I co-founded a communications company serving underserved communities, built it across software, networking, infrastructure, operations and product, solved the problems of VoIP, call routing, billing, reliability and operating cost, and eventually saw it acquired. My involvement did not end at the closing. I kept helping the acquiring company as a consultant.

That gave me a view of software I had not had as a founder. Building your own startup, you are focused on getting the product working, finding customers and keeping the company moving. After an acquisition the priorities change. The technology has to fit a larger organization. Knowledge has to move out of the heads it lives in. Existing systems have to keep running while the people around them change. And technical decisions have to serve people who were not there when the platform was built and will not have you to ask.

Ownership of software does not end when the person who built it leaves. A good system is understandable and maintainable by whoever inherits it. That is the principle I now push hardest when I lead engineering teams: build software other people can operate, maintain and improve, and never software that depends entirely on its author.

A fitness platform on Laravel, React and Python

A fitness startup I helped ran on Laravel for the backend, React for the interface, and Python for scraping and collecting the external data the product depended on. A different product from telecom or mobile, and a familiar set of problems: a backend that carries the application logic, a frontend people can use, and a way to gather and process data that lives somewhere else.

Combining several technologies works when each has a clear job, and it adds complexity whether or not anyone planned for it. How the pieces talk to each other, how data is processed, how failures are handled and how the whole thing is maintained all have to be decided, and a small team cannot afford operational complexity it did not need. External data has its own failure modes. A scraper that works today stops working the day the source changes its markup, so it needs error handling, monitoring, validation and someone who expects to maintain it, and it has to respect the access rules and legal requirements of the sites it reads.

Different tools work well together when each has a clear purpose, and the architecture should help the team ship the product rather than become a second product to maintain.

A wholesale VoIP business on open source

Telecom has run through most of my career, so when a wholesale VoIP business needed building I was on familiar ground: open-source telecom infrastructure on Asterisk and OpenSIPS, with a Yii application for the business side of the platform. Wholesale VoIP is unforgiving in a way most web products are not. Real-time communications, carrier relationships, call routing, billing, network performance and reliability all sit on the same path, and a small technical problem has an immediate financial consequence. Calls that fail cost customers. Routing that is not optimized costs margin. Billing or usage data that is wrong costs revenue and trust at the same time.

Open source let us build serious telecom capability without writing every component ourselves. It did not make the platform free to operate. It still needed engineers who understood the technology, infrastructure, monitoring, security and people who could troubleshoot at the wrong hour. The Yii application carried the customers, rates, accounts and reporting, and the telecom stack carried the calls, and the relationship between those two was the business. In wholesale VoIP, engineering decisions set service quality and operating margin directly, and cutting cost that makes the product worse is not a saving. I wrote about that balance in routing as a business decision.

A real estate platform on Go, React and Next.js

A real estate technology platform I worked on, leading a fully remote team, used Go for backend services with React and Next.js for the web application on AWS. Real estate users expect fast search, clear information, a responsive interface and property data they can rely on, and the stack supported that well: Go for solid backend services, React and Next.js for the interface and flexible rendering.

A modern stack does not make a product. The work was designing the system around what the users needed: how information is organized, how quickly someone finds what they are looking for, how the frontend and backend share the load, what belongs on the server, and how the application stays maintainable as the product changes. Those questions matter more than which framework is popular this year. Startups make it easy to fall in love with architecture, and much harder to confirm the architecture fits the business. A startup rarely needs a distributed system on day one. A straightforward design is usually the better call, and complexity can be added later when a real reason shows up, which is the argument I make in the hidden cost of software architecture.

A 360-degree virtual tour app

A 360-degree virtual tour application, built on Rails and React with A-Frame for the immersive view, was a different kind of engineering. Instead of forms, APIs and database rows, the product had to deliver an interactive visual experience: large image assets, rendering in the browser, navigation between scenes, and acceptable performance on whatever device the visitor happened to be holding.

The user experience carried the product. Nobody should need instructions to walk through a virtual room; moving around has to feel natural or the tour fails at its only job. Delivering rich media efficiently meant thinking about file sizes, loading order, bandwidth and device capability at the same time. It was a reminder that software engineering is not only backend architecture, and that making sophisticated technology feel simple to the person using it is frequently the hardest part of the build.

What they had in common

The biggest thing I brought to those projects was pattern recognition from the ones before, more than any programming language. After carrier networks, telecom, software, infrastructure and engineering leadership, the same needs show up under every product: reliable infrastructure, software that can change, security appropriate to the risk, a delivery process that actually ships, an understanding of what the thing costs to run, and someone who can connect the technical decisions to the business priorities. Every startup in that table needed all six, and none of them needed a framework.

What startups need from a technical leader

One of the most expensive mistakes a startup can make is assuming that more code means more progress. I have watched teams spend months on features nobody needed yet, adopt architecture they were not ready to maintain, and choose technology because it was interesting rather than because it solved a problem that existed. I have written about that pattern as engineering work nobody needed.

When I work with a startup I try to understand the business before I recommend anything technical. What are we trying to accomplish? Who are the customers? What has to work for the business to succeed? How much time and money is there? What do we build now and what can wait? The answers drive everything from architecture to who gets hired. Sometimes the right decision is a custom application. Sometimes it is an existing service. Often a simple monolith is enough. And sometimes the most valuable thing an engineering leader can do is explain why a feature should not be built yet, which is rarely the exciting answer and regularly the one that saves the company months.

Being hands-on still matters

Even after moving into engineering leadership I have kept working directly with the technology, because I enjoy it and because it is useful. My background runs through networking, Linux, telecom, backend and frontend development, cloud infrastructure and architecture, and that range lets me see past individual components. If an application is slow, the cause may be a query, a backend bottleneck, a network issue or an infrastructure setting, and the frontend engineer staring at the browser cannot see any of them. If cloud costs are climbing, the answer is usually in application behaviour, resource utilization or the architecture, and only rarely in buying a different service.

On a small team that is a real advantage, and it is also a trap. Technical leadership means helping the team understand the system, make good decisions and grow more capable, until the product and the team can succeed without depending on one person, which is a different job from solving every problem personally. I have thought about that trap more than most, having been that person at my own company, and I describe how I try to avoid it in how I mentor engineers.

The founder perspective

Having founded and sold a company, I know the pressure founders carry. There is always more to do than time or money allows. Every investment matters, every technical decision has an opportunity cost, and you are often deciding without the information you would like. That changed how I evaluate technology. I do not ask only whether it works. I ask what it costs to build, operate, maintain and eventually replace; whether the company has the people and skills to support it; how fast the business needs to move; and what happens if the product succeeds and demand grows. You do not want to over-engineer a product that has no customers. You also do not want something so fragile that the company stalls the moment it starts to grow. Finding that line is one of the most interesting parts of the work.

From hybrid mobile apps to fitness platforms, wholesale VoIP, real estate technology and virtual tours, every engagement brought new technology, new users, new requirements and new problems. My responsibility stayed the same: understand the problem, help the company make good technical decisions, build something useful, keep the architecture appropriate to the business, manage complexity and cost, and leave the people involved better at what they do. After more than two decades I still enjoy building software. What I enjoy more is helping a company take an idea and make it real, because a startup does not succeed on the latest framework or the most elaborate architecture. It succeeds when it builds something people need and finds a sustainable way to deliver it.

Short answers