Written by: Ivan Moscoso, VP of Engineering at Wyzant
Conventional wisdom says any debate on the best tech stack for building a startup doesn’t matter: the right choice is the one you can stick with. I believe any differences in language or framework are minor compared to the challenge of proving a business model. Yet once you are off the ground, differences can start to matter, and knowing when and how to revisit early assumptions is important — too early and you risk spreading your development efforts too thin, too late and sunk costs (of decisions based on decisions based on even earlier decisions) limit your ability to change at all.
I’ve seen this play out on both sides, and it’s what’s made it clear to us at Wyzant to continue to evolve our technical roadmap. The approach I’ve taken is to apply three criteria to changes we make as a team:
- Accelerating development (maximize time spent on features)
- Investments in system architecture (manage costs of supporting the business)
- Quality and automation (increase turnaround for the above)
Having this criteria helps particularly where benefits need to be weighed against the risk of early adoption. With that said, there are a few changes in the past year at Wyzant that have been well received:
- Docker: All new services are container-managed, and existing ones have been migrated to Docker where possible (we are using Kubernetes to handle orchestration).
- Vue.js: For interaction-heavy parts of the site, we adopted Vue last year as a relatively lightweight option to other front end work.
- Go: We have several Go services in production. Excellent performance characteristics aside, Go has greatly simplified operations and improved developer productivity.
These changes (in addition to others) have one thing in common in that they are complementary to our existing stack. Go is excellent for some backend applications, Vue for some client-side applications and Docker for simplifying aspects of deployment and operations.
There are a lot more details and learnings to share about these examples, but the change I’m most excited about has far more potential impact at Wyzant — migrating full-stack development entirely from .NET to Rails going forward.
For some background, Wyzant relied on .NET since the beginning, and while it’s helped prove our business model, we are far more diverse in terms of the technologies we use and the experiences we bring with us as developers. Having given this a lot of thought the past year, we decided that our way of building features needs to reflect our strengths. It’s not enough for a full-stack framework to just interoperate — it needs to make integration with how we work and what we work with seamless and easily adaptable to change. Ruby as a language and Rails as a framework provide much of what we need to make this happen.
Pushing our business forward means revisiting earlier product assumptions that made .NET an initial choice. Features like websockets, more customizable permissions, API versioning and better caching and debugging tools matter more.
As our platform matures, integrating with third-party systems also means a higher bar to be met for third-party clients. As an ecosystem, Ruby still hits a sweet spot for many of these integration needs. As a framework, along with placing a premium on developer productivity, Rails still addresses many challenges companies like ours face as we continue to grow, and facilitates a strong ecosystem and developer community.
To echo an earlier point, it isn’t enough for our initial technology choices to approximate what we need — systems evolve in unforeseen ways, and it’s important to rely on tools that continue to work hard for us in ways we can’t always predict. The team’s excited to take this new direction with Rails, and given the success with other investments we’ve made the past year, I’m confident it’s a decision that will serve us well.
.png)
