As founders, we’re builders. It’s in the name. We spot inefficiencies. We imagine better futures. We look at clunky tools, cumbersome platforms, and internal deficiencies and think, “Surely we can build something better ourselves.”

Eventually, we must all learn to temper that bias. We must control our impulses and let them run selectively. This isn’t about cutting corners. It’s all about strategic clarity.

Across startups, there’s a persistent fallacy that building something in-house means owning the solution. It’s a tempting narrative to believe that by controlling every layer of the stack, we command our own fate. But more often than not, the badge of “we built it ourselves” fades quickly when that build becomes a maintenance burden and a distraction from what matters most. Time, energy, and capital are sunk into systems that don’t differentiate, don’t scale, and ultimately don’t matter to the relationships that sustain your business.

What's the problem you're solving, and who are you solving it for? What is 1 thing (maybe 2) that you can do better than anyone else in the world? Where is value being delivered, experienced, and relied upon? The answers to these questions show your center of gravity. That’s where your energy belongs.

When you build only the layers where value is created and trust is built, everything starts to align. You can let go of the rest without losing control. Because control, in the end, is only useful when it reinforces your strengths. Building more doesn’t mean you own more. It just means you own more overhead.

Instead of asking, "what can we build?", consider asking, "what do we have to build?". The goal is not to build everything yourself; it's to deliver the most value as efficiently as possible.

It's not only startups that could benefit from this shift in thinking. While large enterprises may have the ability to build everything themselves without relying on third-party providers, their larger overheads simply make these mistakes more expensive. The cost to build exceeds the cost to buy, and the solution is just delayed from reaching the market. And yet, the instinct to build persists. Not because it's needed, but because it's possible.

How do we decide what to build? What is the purpose of building? Simply put, the purpose of building is value.

How are you providing value to your users, clients, or partners? Which components of your solution are closest or most apparent to your users? The more direct the association between any piece of technology and how your users receive value from you, the higher the probability you should be building or at least composing this part of your solution in-house.

There are many ways to consider the value chain between your technology and users. Much thought has been given to this question within the context of blockchain layers, and we recently added a few of our own contributions, updating these thoughts to consider the emergence of AI as well.

So with all of this in mind, let's get tactical. What should we build and what should we buy? To ground the discussion, we'll need to make a few assumptions. If your insight is a new design for a more efficient AI chip, then you're going to build hardware. If your a specialist in language design or databases, that's what you'll build. But let's just assume that we're dealing with something closer to the realm of a consumer application or B2B SaaS. For better or for worse, these are the most common foci for new startups anyway.

Internal tools
It can be tempting, but building custom internal tools is never going to be worth the effort for an early stage startup. No CRM is a perfect fit for your unique funnel and every project management tool is going to frustrate you sooner or later, but building your own is never worth the effort at the early (or even growth) stage. By their very nature, these tools are internal and therefore furthest from providing your users with direct value.

Now if, in your extreme frustration, you have a eureka moment about how a massive frustration can be solved for your team and many others, then congratulations, it may be time for a pivot! You might be the next Slack.

User auth and Email
If you have users, you're going to need to let those users into your platform. You're going to need user authorization: user management, password recovery, and two-factor support. You're also going to need to send these users emails, both promotional marketing emails and usage-related transactional ones.

Users are not going to remember much about your login screen, and most authorization providers let you fully customize your UI components anyway. Meanwhile, the optimization of email deliverability is both extremely finicky and rather important to ensure your emails don't end up in spam folders, never a good look for a company.

Cloud Storage
If you're working in web3, fintech, or healthtech, you likely place great importance on keeping your user information secure and are cautious about where and how it may be shared. This can lead to the temptation to avoid public clouds and attempt to leverage a private cloud solution. While there will hopefully be a time when this investment is worthwhile for you, that day is likely not today. Keeping sensitive data away from third parties is a sound thought, but you must also ask if your own security measures will be as robust as those of cloud providers that already have extensive certifications to handle sensitive financial, medical, and other data.

In addition to it not being critical to your overall user experience and value generation, user authentication presents the same sort of concerns. Third party authentication providers maintain a deep expertise and make considerable investments in their security practices that are very difficult to match in the early stages of your journey.

L2 or L3 Chain
It's possible that blockchain technology is the key unlock for your solution. New financial markets, supply chain platforms, novel social networks, and more can all be powered by innovative applications of web3 tech. If web3 is central to your product offering, it might feel like a necessary step to create your own chain.

The development of a new blockchain protocol may not have the same hardware costs as training a new AI model, but the engineering and research teams required still make this development a massive undertaking. Moreover, any startup building its own chain sacrifices substantial network effects they may otherwise benefit from. You lose access to thousands of developers already familiar with established smart contract platforms, along with existing liquidity that could have otherwise easily followed in the direction of your marketplace or financial products.

Instead of building a new chain architecture, consider deploying an L2 (layer 2) or L3 (layer 3) network using an existing technology stack like the OP Stack or Orbit chains. By using an existing L2/3 framework, you gain seamless interoperability to the larger web3 space of applications and liquidity for your users and can tap a large pool of experienced engineering talent.

That said, deploying your own L2/3 from the very start is still likely overkill. Major DeFi protocols such a Uniswap and Frax started out building on major public chains and only moved to proprietary L2s of their own (still built on existing frameworks) once they had 100s of millions in volume. Likewise, Coinbase was already a publicly listed company before their L2, Base, was released, while Robinhood has only just announced its own plans for an Orbit chain.

Unless you have specific needs, likely based on a particular regulated or highly centralized industry, that require the use of a private set of network participants to validate transactions or are at the point where transaction costs are becoming prohibitive for your budget or your users, you can likely save this for further in your roadmap.

Native mobile Apps
Depending on whose data you trust, somewhere between 60% and 70% of all web traffic comes through mobile devices. While there's a great deal of variance between regions and industries, mobile is irrefutably important in 2025. So every startup should prioritize a mobile app then. Right?

Possibly, but not necessarily.

While having your product available via mobile is a must, especially if you're targeting end consumers, this does not mean that a native mobile app, written in Swift for iOS or Kotlin for Android. Instead, you may consider starting with a PWA, a Progressive Web Application. PWAs can be installed, operate offline, and closely resemble the feel of a traditional mobile app, while using the same web framework that you are likely already using for web/desktop. With a PWA there's less code to maintain for your growing team, and you get to bypass the frustrating operations processes required to list and update your application via the App or Play Store. Finally, the pathways to migrate from a PWA to a native application are becoming easier thanks to tools like React Native and NativeScript.

There may still be performance differences between your PWA and a native alternative. If you rely on heavy graphics or animations or make extensive use of integration with other apps on the phone or pieces of its hardware, you may need to forgo the step of a PWA and skip straight to a native app for each mobile platform.

AI agent framework
If your product relies heavily on AI, you might be tempted to adopt frameworks like LangChain, CrewAI, or AutoGen to orchestrate complex workflows. But most business problems don't actually require sophisticated multi-agent coordination. You likely just need straightforward API calls, basic prompt management, and simple workflow logic, all things which may just be simpler to develop internally.

The AI tooling landscape is still extremely young, with frameworks frequently changing APIs and adding breaking changes. Keeping up with framework updates can become a significant maintenance burden when you could be focusing on your core product. Building your own orchestration gives you predictability without the overhead of learning rapidly evolving tools that may be solving problems you don't have.

Fine-tuning a model
If you're using AI as a central piece of your product, you might believe that developing a better underlying model is what's needed to give you an edge, to make your product smarter. Unfortunately, best-in-class models can cost north of $100MM to train just in compute resources, not accounting for the teams of researchers and engineers required to make a new model a reality. Even the much discussed $5MM price tag of DeepSeek v3 is likely a massive undercount of the true cost of the model's development, even if it still managed to lead the field in cost efficiency.

While developing a new foundation model might be out of the question, fine-tuning an existing model can be a cost effective means of giving the AI within your product strong industry expertise and make it feel very personalized to your offering. Fine-tuning can be done with only a few 1000 data points and can be completed in days or weeks for hundreds instead of millions of dollars.

Fully customized design language and UI
Your user interface is how users experience your product's value, making it one of your most important investments. A thoughtfully designed, custom UI communicates professionalism, builds trust, and differentiates your product when competitors have similar features.

Tools like Figma let you create sophisticated design systems and generate code specifications that developers can implement directly. Modern component libraries, such as Skeleton or Chakra, provide building blocks for custom interfaces without requiring you to build every element from scratch. Users immediately notice whether your product feels polished versus cobbled together from templates. And unlike backend infrastructure they never see, every pixel directly impacts how they perceive your core value proposition.

Building with purpose requires clarity and strong internal alignment. In organizations that build too much, we often find a pattern where technical leadership is more motivated by novelty than necessity, and non-technical leadership doesn't know enough to define what is in fact necessary. While this might feel like a natural and inevitable division of labor, it can quickly doom an endeavor to burning through its runway on pointless side quests.

In contrast, teams that succeed not only focus obsessively on their means and architecture of value delivery, but they also embrace internal education. Every team member must embrace the role of educator. Sharing their context with colleagues to improve everyone's ability to make decisions.

You don’t win because you built it yourself. You win because you built the right thing at the right time, with focus, speed, & purpose. Developing technology just for the sake of doing it in-house makes it harder to deliver and capture real value. Your in-house solution must continually be maintained, becoming the shadow your team works under tomorrow, stealing time, energy, and ambition from what truly deserves it.