One of the overwhelming tasks startups often face is how to build a Minimum Viable Product (MVP) that is scalable and effective. In subtle ways, scalability involves much more than handling increased workloads efficiently. It fundamentally impacts engineering culture, job satisfaction, and more.
It also extends to a product’s adaptability by influencing its ability to integrate efforts of new engineers, foreseeing impact of decisions on future costs, and ensuring flexibility as market demands change. This guide introduces the food truck approach as a strategy for building MVPs that are both scalable and effective.
🔥 New Venture Tip: As you start a new MVP, be sure to grab all the freebies you can. Startup programs from Microsoft, Github, Notion and AWS are well worth the time it takes to apply.
The Food Truck Approach
The food truck analogy simplifies complex technical concepts, making discussions accessible to everyone within an organization. It enhances understanding across departments and equips non-technical stakeholders with invaluable insights, fostering better collaboration.
Engineering as the Catalyst for Clarity: Engineers play a crucial role in translating complex technologies into understandable terms. Success lies in the entire team’s deep comprehension of both the problems faced and the solutions provided.
The components of a software project are analogous to the elements of a food truck. Strategically, we focus most of our energy on the menu and grill, without neglecting necessary components like the frame, keys, and wheels. Keep in mind that the grill is the most important part of the food truck, and if it’s not core to the business offering is prime for open source.
The Product Menu
A product mene translates business needs into tactical plans. Tools like Jira are common, but direct documentation often works better. Start with alignment on plans, document thoroughly, and keep a clear “definition of done”.
Dropping an open source documentation project inside a project repo helps get the ball rolling and can easily be deployed via CICD.
Below are some great options:
Shout out to Meta, Docusaurus is a great option for a React based documentation site. We leverage the blog feature to keep stakeholders informed and keep a play-by-play.
Material Mk-Docs by Martin Donath works well if you prefer python.
Frame, Keys, Engine and Wheels
Early decisions on cloud providers, frameworks, and infrastructure set the foundation. We opt for technologies that aim to help bring production solutions to market quickly.
Keys
Security and compliance are ongoing and start very early in the lifecycle of the product. Unless security is core to your offering, it’s best to implement one of the market leading solutions. Auth0, AWS Cognito, etc.
Wheels
When researching potential open source resources, find homogeneous dependencies that are well supported and thoroughly documented. Searching github for your desired technology paired with the word “awesome” is a great way to find a curated list of options.
Engine
Deployment methods matter. I prefer to leverage GitHub actions for CI/CD, invoking AWS SAM for infrastructure as code deployment. AWS SAM is a great tool for deploying serverless applications. Below is an example of how we deploy our production environment in just 2 lines of code (assuming that a s3 bucket exists).
sam build --use-container -t infrastructure/production.yaml
sam deploy --stack-name example-prod --s3-bucket example-bucket --capabilities CAPABILITY_IAM --region us-east-1
Other great options for infrastructure wrap CloudFormation in something a little more manageable for many. The Remix framework pairs well with architect, and is another great option. Check out Stacks like the Grunge Stack by Kent C. Dodds for a great starter template.
If you look above you will observe that we run a few steps in our workflow before deploying to AWS. We like to validate our code and make sure it passes a few essential smoke tests.
You will also notice we deploy our documentation to Github pages. Each of these steps is relatively simple. Shout out to peaceiris, with their github action.
- name: 🏗 Build
run: cd docs && npm install && npm run build
- name: 🚀 to GitHub Pages
uses: peaceiris/actions-gh-pages@v3
with:
github_token: ${{ secrets.PAGES_TOKEN }}
publish_dir: ./docs/build
user_name: therealsiege
There may be much more to your food truck engine, but let’s not get distracted. Let’s keep our overarching goal in mind which is to focus on the grill without neglecting any one component.
Testing & Visibility
External Alerts
3rd Party Dependencies: Many 3rd party services you come across will provide a status page. Take advantage of this by setting up notifications and make sure your organization is aware of any potential issue.
Logging
Surface standard out and standard error: Ensure visibility into the system. There are tons monitoring tools to choose from. Don't allow your production application to become a "mystery box" to your engineering team.
Automated Testing
Test driven development has been a staple for years, arguably causing test suite bloat. The goal is to limit testing to critical features, as well as features that require human interaction. Our strategy has been to ensure unit tests cover business logic. In addition, browser/device based testing ls leveraged to be more thorough (but run less often). Cypress and Playwright have been amazingly useful, especially if you remember the codeception/selenium days and adding arbitrary waits().
Writing tests for the sake of coverage can have terrible consequences, and is flat out ugly. Unnecessary testing hinders the development workflow and causes unnecessary frustration. Engineers begin to resent the safety net and become entangled in a web of wasted time.
Check out CUPID — for joyful coding by Dan North for more.
Feedback
In app bug and feature requests
Try to keep everything as accessible as possible, gain feedback directly from your prototype, and don’t forget a link to your docs. Marker.io and bugherd are great options for keeping track of these requests and ensuring they are captured.
Stakeholder Demos
Establishing feedback loops with stakeholders, through in-app requests and regular demos, keeps the project aligned with user needs and business goals. While important, this can be extremely intimidating (especially for the 🙋‍♂️ introverted engineer).
Here are some tips for successful demos:
- Schedule often, weekly is an awesome cadence.
- Demo from a live environment, not localhost.
- Be prepared, use your developer blog to lead the discussion and ensure everything is covered.
- Tie engineering tasks to business objectives.
- Be straightforward with scope creep and expectations.
- Surface any questions, take notes and review new feedback.
- Send out a follow-up email with the notes and any action items.
The Grill
With the foundation set, focus shifts to the product’s unique features. The “buy, build, or partner” decision is critical at this juncture, balancing innovation with practical dependency management.
- Dependencies are a two-way street, make sure you understand each one and have a backup plan if any one of them disappears.
- Complete the business objective (steel thread), sometimes it’s easy to get discouraged, keep it simple.
- Iterate, and keep taking baby steps towards objectives and goals set by the business.
- Keep the grill clean, and don’t forget to document your work. Remove any dependencies that didn’t make the cut.
The “Food Truck Approach” offers a framework for building scalable, understandable products. It’s about collaboration, clear communication, and focusing on what truly matters: delivering value to users while fostering a cohesive team environment.
Good luck! 🍔
P.S. - Shoutout to Gene Harker and Matt Wimberley for helping me refine.
Top comments (0)