10 Things Learned Making a Web App For 6 Weeks

In July I set out to hack on a web app I wanted to build, called StoryEven. Today is the last day of that exploration.

You can check out the alpha version here @ storyeven.xyz

It’s a super simple web tool that you can use to add headings at the right* spots in your writing. Here it is on Github.

Bookmark it & try it out when you’re editing a long document.

I explain why I built it here.

Here’s a quick brief video on how to use it.

*right = after about every 250 words, at the very least


  1. Building in public works. I would have flaked out due to all the annoying issues I experienced on the way. But because I had announced it, I had to keep going.
  2. 6 weeks is too long. Parkinson’s Law definitely kicks in. I worked on it ~ 1 hour daily. 40 hours stretched into 6 weeks is about 4 weeks too long.
  3. 6 weeks might be OK if you have other things going on. This project also wasn’t exhausting to the point where I had to dedicate all my time to the work on it to finish. Had I set it at 2 weeks, I could have had an (even more) half-baked product.
  4. The platform matters. I picked Netlify for this project because I had wanted to explore it for a long time. Netlify was super easy to use, but my app required Node to run, and Netlify is not meant to run Node (except for build tasks). I compromised and made it work, but it would have been much quicker to set up had I used a different platform.
  5. Git usage goes up on real projects. Up until now, I’ve been hacking on scripts in VS Code. Good for learning JS, but not very realistic for the actual job of building software. On this project, I was able to start using Git daily, and even applying some less well-known methods. Since I was hacking alone, I didn’t get to use all the functionality, but it was definitely better than none.
  6. Vanilla JS is cool, but frameworks exist for a reason. I wanted to do it in as much vanilla JS as possible (still had to use jQuery a bit). But I can see how using React or Next or something similar would have made parts of that work much easier. My project didn’t need their scalability, but their build automation can be helpful.
  7. Don’t start hacking right away. I wrote a PRD which helped me clarify who this was for (NOT bloggers who have many writing tools), among other things. I also made a story map and later refined it further. Those pieces helped me think about the problem and to deliver what I could deliver in the allotted time. A story map was helpful to work through the whole journey of using the product, not only the core of it. It also allowed me to leave out some functionality without giving up on it entirely.
  8. Documentation must be alive. My first story map sucked because I had no clue what issues I would run into. It also didn’t have some elements I later thought of later. My PRD stayed the same, but I am changing it based on feedback from this version. Point is, these documents must live. Your learning must integrate into them.
  9. Get feedback sooner. While I know about the benefits of continuous discovery, I was afraid (and still am!) to share what I worked on. It takes a lot of mental work to be able to do this, and likely why startups don’t do it enough. Knowing about the trap doesn’t mean you avoid the trap.
  10. I root for the engineers even more. While they get paid well, engineering life is not easy. Stuff breaks, stuff doesn’t work, you have to figure out new technology on the go. If you have unrefined stories, you end up procrastinating and any progress is a pain. You also don’t feel like sharing this half-baked work even if though you know you must share it sooner than later.

So, have you tried it yet? 🤑

Leave a comment

Your email address will not be published. Required fields are marked *