My team at thoughtbot works with founders, entrepreneurs and early-stage start-ups. Often they don’t have a technical team member, let alone staff developers or a codebase. Many of these folks look to thoughtbot to play a CTO role: guiding them in their technology choices while building a new product.
So in the absence of any technology footprint, how do we help founders pick the right technology tools?
thoughtbot has a standard tech stack with some good defaults. We recommend Ruby on Rails for web backends, JavaScript and Next.js for web frontends, Postgres for databases, React Native for mobile apps. But we’re very clear with our clients that every consulting agency they talk to will have a different set of defaults. These are a starting place, but our technical choices should be a consequence of the business strategy.
So after laying all this out we have a conversation, using these guidelines to come to a decision.
Domain-specific toolchains
Do we need to build a product that requires a specific toolchain? For example, Python is a good choice for AI products because that’s where the AI ecosystem is at.
Do we need advanced mobile functionality? Perhaps a complex Bluetooth feature or a media-heavy app? Building with Swift or Kotlin may be smarter than using React Native.
Are fast webpages essential? Maybe the target customer will have spotty internet or SEO is critical. We may choose a tool that offers powerful caching or static site generation.
Do SaaS partners support the language? If we know we need to integrate with a key API, we may choose a language for which they offer an SDK. In 2024 a lot more companies are offering JavaScript SDKs than Ruby SDKs.
Team skillsets
Does the team staffed on the project have specific skillsets? We’ll be able to move faster if we’re not learning on the job.
Does the founder have strong opinions about the technology? Maybe they’ve been burned in the past. Is the founder bringing on a CTO with strong opinions? The last thing we want is for a CTO to come in and ask for a rewrite.
Consider your junior developers
Small businesses need to move fast and that often doesn’t leave time for training up junior developers. It may be best to pick tooling where it’s easy to onboard devs who don’t have a lot of experience. Some languages are more accessible than others. Fresh devs right out of school aren’t learning Ruby but they are learning JavaScript.
Does the language or framework use patterns that help junior devs fall into the pit of success? Does it feel too magical? Rails’s magic can be confusing and intimidating.
Moving quickly or moving safely
When working with founders on new products we usually want to move very fast. We often have a goal of delivering a minimum viable product in 6-8 weeks, or creating a proof-of-concept even faster. But for some industries – e.g. healthcare or education – the regulatory environment dictates a slower pace in order to ensure compliance.
Are we building something quick and dirty or long-term maintainable? We often find Ruby on Rails to be more maintainable AND faster for a few reasons:
- its powerful testing tools make it easy to write unit tests and end-to-end tests
- its ecosystem is not as tumultuous as JavaScript’s
- its opinionated standards avoid decision fatigue and act as guardrails. JavaScript is more of a wild west
Building a company
How easy is it to hire devs who know the language? How expensive is it? In 2024 there are a lot more JavaScript developers on the market than Ruby developers.
How many developers can the company afford to hire? Small teams will need each developer to work across the entire stack. Using JavaScript for the frontend and backend makes this easier.
Will investors or potential acquirers be put off by the technology? I’ve heard anecdotally from a founder that venture capitalists and acquiring companies might be more likely to fund or buy a company that’s using a trendy language like JavaScript.
Make a choice and test it out!
There’s no perfectly correct decision here. Avdi Grimm even suggests rolling a dice to choose. But if you use these heuristics you’ll at least be able to explain why.
Whatever we choose is not final. If these initial choices don’t work out, we can usually pivot quickly. And tech products don’t live forever. The MVP we build will often be replaced or modified beyond recognition so that it can scale. Our goal is not to choose the perfect tech stack, it’s to choose one that’s good enough to build your successful product.
