Are you launching an app with user-generated or rich product content? At some point, you’ll need a steady infrastructure for receiving, processing, and delivering files. To save you time on feature planning and research, we’ve drafted a high-level tech spec with all the traps and pitfalls.
A tech spec? Seriously? Yep! As you will soon understand, implementing a “Choose a file” button is just the tip of the iceberg: the whole project will need an architecture overview. Use our cheat sheet to create your own tech/product spec or simply glance through it before story mapping.
💡 This cheat sheet will bring the most value to media-heavy platforms like website builders, CMSs, marketplaces, and marketing automation platforms.
Intro: Giving the Whole Thing a Real-World Vibe
Let’s imagine you’re building a next-gen CMS. You will need a fully fledged file management system to enable your customers to upload content to their websites and landing pages.
Let’s call this functionality UploadUFO and map it out using a popular tech spec template from Lyft Engineering, as their approach seems simple and well thought out. There are eight key sections, and we’ll cover all of them right now 👾
1. Creating a File Handling System: Overview
Here you should describe all the “what”s and “why”s of the project. What kind of uploading functionality is UploadUFO? What user jobs will this feature be implemented for? Why do you need to build it now? Wrap your answers into a concise summary.
Got it? Here we’ve described our vision, making the feature a part of the product and business reality.
2. Goals and Impact Measurement
List all the desired outcomes so that you can evaluate the results at the end of the day. The more specific your goals are, the better. That’s why it’s crucial to introduce relevant metrics and their approximate values.
3. Identifying Non-Goals
Identify what you are intentionally not building to formalize the scope and prevent feature creep.
4. Feature Planning
Here you will need to identify your engineering approach together with key infrastructure elements. This part will be the longest one and should be based on in-depth research.
First, define the big picture: how will the whole file handling system function? What are the crucial elements, and how are they connected?
Then you’ll need to describe each element. We gathered all the possible requirements and split them into four main parts: uploads, storage, processing, and delivery. To decide what’s relevant for your project, go through the points below or download the checklist in PDF format.
Decide whether you’ll need to support all sorts of files. Consider multipart and resumable uploads, especially if you plan to receive large files like videos or high-res graphics. Think about possible security issues, as the uploading process is the weakest part in terms of potential hazards.
|File types:||UX:||Performance and security:|
Crazy large files
|3rd party sources like Dropbox or Instagram|
I18n and L10n
Network issue handling
File shrinking upon upload
Your storage will need to be secure and able to scale as you grow. If you’re planning to handle personal or health data, you’ll have to make sure it’s HIPAA and GDPR compliant.
|HIPAA etc. compliance|
For this part of the scope, the sky’s the limit: you could even include AI-powered features like object and color recognition to automate content management. But be careful to avoid feature creep.
|Performance and security:||Content insights:||Content optimization:||Content processing:|
Explicit content checking
Face and object recognition
Advanced external APIs
GIF to video
Conversion to next-gen formats
To deliver the content fast and tailor it to the individual’s context, you’ll have to think about serving it from different locations and building automated responsiveness: on-the-fly destination properties detection, resizing, and cropping.
Auto format switch (e.g. WebP, GIF to Video)
Auto size detection
HIPAA etc. compliance
5. Security, privacy, risks
File uploading is one of the riskiest parts of the process in terms of potential hazards and malware, so ensure your infrastructure is bulletproof.
Another potential risk can be related to scaling: a basic in-house infrastructure will endure the MVP stage, but what if you grow to thousands of customers? To foresee all the risks, it’s recommended to ask your stakeholders for a tech spec review.
6. Other Considerations
In this section, you should describe alternative ways of solving the problem and why you chose the approach you described in the Planning section.
For example, here you can list your ideas around the classic build or buy dilemma: should the infrastructure be built from scratch, be composed of different outsourced components, or fully outsourced?
If you opt for a completely DIY solution, a fully fledged infrastructure with all the above elements covered can take up to 2-3 years to build. Deciding on what to buy or build could reduce this time frame dramatically.
|In-house||Open source solutions and partial outsourcing||Out-of-the-box|
|Time to market||2-3 years||1-2 months||Less than 1 day|
|Maintenance||50+ hours per year||50+ hours per year||0|
Plan the project milestones in line with the development strategy you choose, defining particular dates. Make this planning true to life and change dates if you move faster or slower than expected.
8. Open Questions
If there are still blind spots or areas you lack expertise in, list the questions you could ask your stakeholders and industry experts.
If you decide to use this tech spec, refine it by showing it to your teammates, stakeholders, and other interested parties. In case of critics, don’t give your reviewers the cold shoulder: they’re helping you to create the best possible solution.
If you’re a tech spec renegade and hate waterfall-ish approaches, just take all this information to the story mapping session and get your kudos from the team.
P.S. Laying the Cards on the Table
The UploadUFO functionality we described is actually inspired by a real-world project that was released by Shogun, a powerful drag-and-drop page builder for online stores. The team needed to implement file handling functionality that would:
- Outsource the image handling burden
- Reduce image bandwidth and hosting costs
- Speed up production and time to market
- Ensure reliable delivery
As a result, Shogun cut 86% of image bandwidth costs, achieved 1.5% page load acceleration, and saved three months of development time, resulting in a $200,000 overall savings.