Power of a single HTML file for MVP apps development
TL;DR
Interactive single HTML file demo page is below. Play with it and then return back to get the insights! On the left half of demo you click, on the right half you filter those clicks. Simple and clear.
In search of MVP
Minimum Viable Product — is not a “minimum functionality”, not a “minimum features” product. It is a “minimum viable in this world” product. It can live in this world because it is self-sufficient. It doesn’t ask for credits. It is self-profitable.
And in search of this MVP we search for a product that addresses 5 types of risks (taken from Marty Cagan, CEO of SVPG interviews):
- Value risk. Would they buy it? Would they choose to use it?
- Usability risk. Will they figure out how to use it? And if that’s easy and intuitive for them to use it?
- Feasibility risk. Is this technically possible? Do we have enough people in our team who know the technology? Can we make this product when we need it?
- Viability risk. Can we make it cost-effective? Can we sell it at a price that keeps this product profitable over its lifetime?
- Ethical risk. Should we build it? Is it ethical thing?
So, a lot of risks to address! A lot of stuff to do!
In a Dual-track Agile these risks in searching of an MVP are addressed during a product “Discovery” phase:
When we found that MVP that looks like addresses all these risks (the risks still remain, but they are minified, they look like addressed with the evidence) — I mean, when our potential users and customers look at our MVP prototype and ask us: wow, where can we buy this, how can we buy this? Then we switch to “Delivery” phase and deliver our first real product.
It turns out that from our first version of the delivered product that was really sold in a competitive market and users started using it to a point of “Product Market Fit” where this product earns money that cover all its operation costs and starts to be considered as a general solution in its problem area, when it becomes a synonym of a solution for the problem (for example, if you need to keep your code somewhere and you don’t have your servers, then you might have think: “GitHub” — and this is because GitHub got to a “Product Market Fit” point when it is considered as one of general solutions in that problem are) — we’ll need 3–4 iterations of that delivered product to get there.
This is because these first versions of our product would have their bugs and limitations and drawbacks — and this would prevent most customers on the market from choosing it. But since that first delivered version these drawbacks will pop out and the team will have an opportunity to address them as well.
And what we need — by that moment of 3–4-rd product version delivery to the market — is not to run-out of the money, of people in a team, of time… Clock is ticking agains us. And we have to keep our resources on this way to find MVP, to get to Product Market Fit point.
That’s why in all this “Discovery” and “Delivery” process I would like you to notice this “single HTML file” approach that I suddenly discovered, making my MVP. And I think its brilliant because it allows to go fast and cheap. That’s why I decided to write this article and tell you about it.
Single HTML file for MVP
I’m still very impressed how far we can go with a single HTML file when we are on MVP product Discovery phase (and it even continues to count when we switch to a Delivery phase).
Single HTML file
Single HTML file is a file that you can open in your browser and it will work without any server that hosts it. For example:
<html>
<head></head>
<body>
<p>Hello, world!</p>
</body>
</html>If we save this into mvp.html and open it in ANY web browser on ANY platform then we’ll see the same:
Lets add Bootstrap CSS there:
<html>
<head>
<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0-alpha1/dist/css/bootstrap.min.css" rel="stylesheet">
</head>
<body>
<p>Hello, world!</p>
</body>
</html>
So, now stylish. Then we can add JavaScript code in that file (both in-the-file and imported from remote source) — and file can become interactive.
This was an intro. Now we cook…
Client-server architecture emulation in a single HTML file
JavaScript code in that single HTML file can emulate backend. Code can be designed in a way that some parts of it could be responsible for API operations emulation. Another parts of the code — for database operations emulation.
For example:
class DB {
constructor() {
...
}
insert(...) {...}
select(...) {...}
update(...) {...}
delete(...) {...}
}
const db = new DB();
const records = db.select(...);And these functions could be moved out of the HTML file and imported back in it like this:
...
<!--
scripts emulating back-end cascadly depend from each other:
* db.js independent
* api.js depends on db.js, because interacts with it
* sdk.js depends on api.js because interacts with it
-->
<script src="src/db.js"></script>
<script src="src/api.js"></script>
<script src="src/sdk.js"></script>
<!-- MVP app (from sdk.js) inits when "backend" is ready -->
<script type="text/javascript">
const app = mvp_app({...});
</script>
</body>
</html>These JavaScript files could be loaded from remote host (even from Dropbox or GiHub) and you’ll continue to give your clients only that single page HTML file. They can open it if it is hosted on your web site (or in Dropbox or GitHub) and they can reach it with PCs, tablets and smartphones or they can download it locally and open in their web browsers.
Backend in JavaScript in the browser
In an example above a database — is an in-memory JavaScript class. This means, that all it’s data is available till you stay on that web page and it would be completely lost on a page reload or on tab or browser close.
But we still have a standard, in-an-every-web-browser instrument to address this data loss:
window.sessionStorage.setItem('db', db);This code means, that we can save our database in a session storage of web browser — and the data will be accessible to:
- our file (or page) even on reload;
- to other files (or pages) in the same origin till browser tab close.
So, now this allows us to keep the data and emulate cross-pages operation (for example, we develop an MVP for a web shop and we collect items into the basket) till the user keeps the tab of the browser opened or till she is on our web site!
Not enough? You want to keep the data even between closed tabs? We still have the instruments for that:
window.localStorage.setItem('db', db);That’s it! 5 Mb of sessionStorage and 5Mb of localStorage to emulate operation of our database. And 5Mb is about 1500 pages long average size book. Isn’t it good enough for MVP?
$0 cost environment with CI/CD
Fastest error-prone environment I’ve ever seen
Single HTML file — is an environment, that is deployed in 1 second. You have no issues with rapid iterative development when you deal with single HTML file, because this file + web browser = environment. And this is just brilliant for fast iterations and fast delivery.
You can even make that file content being built like an Electron.js! Let your JavaScript code to completely build what is inside — and your users who already downloaded and tried your HTML file will not need to download a new file version again (or do it quite rarely). They will get your updates from your fast CI/CD process instantly!
This is the fastest deployed and error-prone environment I’ve ever seen in my IT career!
GitHub pages for hosting of single HTML file
If you host your code of that single HTML file on GitHub, then GitHub provides such a service as GitHub Pages. It can publish your HTML files and host them for you for free:
And you even can bring your own DNS name to it — and it will work!
So, thanks to these emulations all the app looks so real! And it is delivered to end-users instantly, because you host and develop JavaScript code and they host or visit hosted HTML file that loads that JavaScript.
For example, this website — is a single HTML page web site published with GitHub pages: https://dotheyuse.com. Go play with it and try to figure out that it is NOT the app that is hosted by huge amount of servers behind!
From MVP Discovery to MVP Delivery with a single HTML file
When we found that MVP and our users “want this for real” we need to switch from Discovery phase to Delivery phase. And Delivery phase is totally for Software Developers. A lot of technical questions to be addressed on this phase! And there’s no better “specification” for developers, testers, designers, operations as a working prototype!
“Prototype as a spec” — is a concept for Product Delivery phase. You just give this working proven with UI and UX single HTML file to Software Developers and they make it at production scale, on servers, with all the CI/CD pipelines needed, covered with auto-tests, etc., etc. But now you give them a clear image of “how the product should look like” and “how it should work” — an interactive prototype with “just make the same, but on servers — so everyone could use it”.
No GDPR issues with single HTML file
As all the data never leaves your users browsers, as it is hosted entirely in your users browsers — you don’t need to add popups and warn people to accept something based on GDPR.
You don’t get their data (even if it looks like you do — you don’t) and don’t store and process it is somewhere — so you are not a subject of GDPR and can save your time and money till you have real product and till you really need to comply this.
Demo
Currently I develop “Do They Use” service and I develop it this way: searching an MVP with a single HTML file approach.
I have various demos for this my app, but for you maybe would be most interesting this “iframes” demo:
This is a single HTML file with “obsolete” <iframe> technology. No one uses <iframes> today. But look on this demo page!
Left half of the page — is a frame with loaded another single HTML file: your_app.html and on the right half is another frame with loaded my MVP app dtu_app.html.
This is a perfect demo to show my users “how my app works”: they interact with (their) “monitored app” on the left side, and then they can see the results of their interactions on the right side in that (my) “monitoring app”. Simple, clear, cheap, fast and easy.
All these 3 files are completely independent from each other single HTML files:
- hosting file with 2 <iframes> to simplify UX of “how it works” demo;
- left frame with customer’s app “your_app.html”;
- right frame with my MVP app “dtu_app.html”.
You can download each of them locally “Webpage, HTML only” and open in browser and each of them will work. You can open them without downloading when they hosted by GitHub Pages and demo will work.
This demo will work in ANY modern browser on ANY platform. And just imagine the cost of all this simplistic CI/CD beauty… $0 for env.
If it was interesting for you to read this article or you have any questions, please let me know about it by leaving a comment and clapping.
