Choosing the perfect tech stack for your MVP depends on quite a few variables. Considerations come from your features, your users’ needs, as well as your business. We help our clients make an informed decision based on these considerations and the goal of their first version. For MVP builds, timeline and budget expectations also come into play.
For early stage start-ups, Jamstack architecture is a great tool to get MVPs to market quickly. But, like any tool, you’ve got to make sure to pick the right one for the job. We’ve put together some considerations that we hope help with your Jamstack consideration.
What is Jamstack?
Jamstack isn’t any one specific technology but rather a whole new architectural approach to structuring web apps. Jamstack takes its name from Javascript (for frontend code), APIs (for backend services), and Markup (for content), but many Jamstack sites also use TypeScript, Python, or Ruby. Jamstack can make web apps that are faster, more secure, and easier to scale. This speed comes from the fact that the whole frontend is pre-rendered and stored in a highly distributed Content Delivery Network (CDN). So, when a user requests the site, the ready-to-go static pages are served from the network point closest to the client. The result: super-fast loading.
With a Jamstack site, there’s no traditional backend server. Instead, things like payments, authentication, content management, search, and data services are outsourced to specialist API services like Netlify, Auth0, AWS Lambda, Stripe and Contentful.
In addition, Jamstack leverages tools (like Git) that developers already love to work with. Unlike other web frameworks, the code and the content of a Jamstack app are tightly coupled in a cloud repository service, like GitHub. Any changes to the code or content automatically trigger a new build of the site. This removes the need to test changes in complex staging environments. So with fast, simple, and safe changes, most “static” Jamstack sites are anything but: sometimes updated hundreds of times daily, just as often as a more complex traditional framework. For our non-technical readers, this means your MVP development can be done quickly and be more engaging thanks to the faster feedback loop provided by Jamstack.
Is a Jamstack MVP right for us?
Because of this, Jamstack MVPs tend to focus more heavily on developing a frontend to consume these backend services, saving the client time and money. Jamstack integrates nicely with a wide library of tools so depending on what you are trying to do, tapping third parties could save you time in alternatively building things from scratch. As the API economy grows, it’s becoming possible to do more and more with Jamstack: from personal blogs to enterprise-size apps serving millions of users.
If Jamstack’s so great, why wouldn’t I choose it?
Jamstack isn’t always a walk in the park. If there isn’t an API that meets your needs, if you need to build some custom backend microservices, or if you have legacy software you need to integrate, then Jamstack could end up not saving you time. In the scenario where our clients have a Platform as a Service (PaaS) or backend that they need to integrate with, Jamstack might not save time if a customization will be needed anyways to make it work.
A big part of early-stage product strategy is digging down into exactly what your product needs, in the simplest first version, and selecting the best tools to achieve this. If you need to combine more than one data source or API, time needs to be taken to figure out how to integrate all the moving parts. As a founder, it’s good to have a high-level awareness of how custom development or multiple APIs can impact your timeline, so that you can plan appropriately - it’s not always a shortcut. Time invested early on in assessing technical feasibility and Level of Effort (LOE) is time and money saved later.
Technical Exploration Tips:
Our developers build new products all the time, and exploring third parties and the technical feasibility is a big part of planning the right architecture. Here are their suggestions for doing so efficiently.
Get started without us - Even if you aren’t technical, you can do some basic research into third parties based on the features you have in mind, the industry and business requirements. Having some initial ideas ready for us, saves at least a week of time. Search online, talk to industry experts, ask questions - there’s a lot you can find.
Don’t skip the Sales calls - Not only will you learn a lot more about their services, you’ll get a sense of how they will be to work with, the structure of their organization, and the technical support they provide. In this call you can ask about basic feature support and inquire about documentation / sandbox access.
Start free trials & try things out - Once we have a list of potential APIs to consider, we look to get access so we can start to test out the APIs. The more thorough the test, let’s us feel more confident in the specific feature requirements that make our product impactful. This shouldn’t be a generic test - really get in there and try to get a sense of how it performs and what an integration would entail.
Documentation, and its quality is telling - Quality API documentation would be well organized, have links throughout to make navigating easy, and have examples that can be referenced. Stripe’s documentation is the gold standard. If the documentation seems outdated or missing details, that should be flagged when thinking through the timeline for integrating. You should buffer in some time to go back and forth with their team and inquire about an available point of contact.
In summary
In our recent projects, we’ve seen Jamstack pushed to its limit and there is definitely a threshold when it comes to time savings in integrations. The good news is - we are here to help. thoughtbot Ignite’s early-stage product strategists are experts at rapid product validation and selecting the perfect tool for your MVP, be it Jamstack or a custom solution. Get in touch today to learn how our team can get your idea to market ASAP without compromising on quality.
