Artifact Log: Stream MVP
What went into creating an MVP in a month and what I learned
Note: Ordinarily, Artifact Logs will be for paid subscribers. I’d like to share this first one for free so I can get feedback and learn what parts of these posts are valuable to readers. Please enjoy!
Over the past month, I embarked on a project to create a task manager app - one that truly aligns with my work style. Yes, you heard me. I'm making a todo list. As someone new to software craftsmanship, I chose to start with a familiar concept. My goal was to develop a Minimum Viable Product (MVP) within a month, not just to build an app, but to learn about the development process itself.
In this article, I'll share my experience of creating this MVP, from initial concept to final implementation. By documenting my steps, challenges, and learnings, I hope to contribute to the broader conversation on craftsmanship. Moreover, I aim to showcase the nitty-gritty details of what it actually looks like to build things that solve problems, particularly for those at a similar stage in their journey.
Planning
To approach this project methodically, I decided to follow a traditional product development lifecycle. This choice was deliberate - I wanted to understand which aspects of this process would be most helpful for a solo developer working on a small-scale project. I began by crafting an MVP specification, leveraging ChatGPT to help refine my ideas and accelerate the process. This initial step proved invaluable, forcing me to clearly articulate my vision and requirements.
With the MVP spec in hand, I took an Object Oriented Design (OOD) approach to start translating the spec into technical designs that I can use during implementation. The first step was identifying key abstractions from the spec. These abstractions then formed the basis for creating Conceptual Class Diagrams, which helped visualize the structure of the application.
Next, I defined attributes for each class, essentially mapping out what would become database columns. This process naturally led to three more OOD exercises: state diagrams, sequence diagrams, and class responsibility cards. Each of these tools provided a different perspective on how the various components of the app would interact and function.
I won't go into too much detail on what those pieces involved, but I will share a collection of "artifacts" at the end of this article so you can see how all of this looked in practice.
By the end of this planning phase, I had developed a solid understanding of the app's structural function. While time-consuming, this comprehensive process provided a strong foundation for the subsequent design and implementation phases. In future projects, I'd likely streamline some of these steps, but for this initial venture, I enjoyed trying to be thorough and seeing what was truly helpful.
Design
Despite the app's relatively simple concept, I knew that good design would be crucial for its usability and appeal. However, recognizing my limitations in this area, I initially decided to outsource the design work via Fiverr, based on a friend's positive experiences with the platform.
To prepare for this, I conducted design inspiration research and used both this and my MVP spec to create a comprehensive brief for the designer. After reaching out on Fiverr and receiving the results, I was a little conflicted. The final design, while professional, didn't align with the minimalist vision I had in mind for the app.
This misalignment led me to attempt my own design, incorporating some elements from the professional version but aiming for a more stripped-back aesthetic. Interestingly, when I shared both options with friends, the consensus favored the designer's version. However, trusting my instincts and the core principles I had established for the app, I decided to proceed with my simpler design.
This decision sparked a deep dive into design systems. I hoped to find one that would complement my app's ethos while elevating its visual appeal. This exploration proved fruitful; having a clear design system not only improved the app's aesthetics but also significantly streamlined the implementation process later on.
Implementation
With the design finalized, I turned my attention to the technical architecture. I had already decided on using Remix for the framework, and Fly.io seemed like the obvious choice for hosting. The next crucial decision was choosing a database solution.
After considering options like Fly Postgres, neon.tech, and Supabase, I ultimately chose Supabase. Its Backend-as-a-Service (BaaS) capabilities, particularly its built-in authentication features, were the deciding factors. This choice allowed Supabase to serve as a generic server with a REST API over a PostgreSQL database, while my Remix server could function as a Backend-for-Frontend (BFF) layer, a pattern I've found effective in past projects.
Setting up the Remix repository and integrating Supabase and Drizzle ORM went smoothly at first. However, I encountered some challenges with authentication due to the sparse documentation for Remix and Supabase integration. I got it working eventually, but once this was in production I could immediately tell something was off. It works, but it's entirely unintuitive as you need to confirm your email before logging in. More on that in the future though.
The next steps involved adding Tailwind CSS for styling and laying out the UI components. With the structure in place, I began implementing functionality, with drag-and-drop capabilities proving to be the largest hurdle.
As the deadline loomed, I had to trim more features than initially planned to meet the MVP timeline. While disappointing at first, this constraint proved beneficial. The leaner MVP allowed me to quickly identify which of my intended choices didn't work in practice. Now, with a tangible product in hand, I'm better positioned to make informed decisions about the next steps in crafting this app.
Despite the challenges, deploying to Fly.io was surprisingly straightforward, bringing the project to a satisfying, if slightly trimmed-down, conclusion.
What I learned
This month-long journey provided numerous insights into the software development process:
While the comprehensive Object Oriented Design approach was informative, I found that focusing on database schema diagrams and sequence diagrams would likely be sufficient for future projects of this scale.
The importance of a well-defined design system became abundantly clear during implementation. I plan to refine the system I developed for potential use in future projects.
Infrastructure setup consistently proves to be one of the most challenging aspects for me. Moving forward, I'm considering standardizing on a single tech stack to minimize time spent on this phase.
The pressure of a deadline, while stressful, served as a powerful motivator and forced me to distill the app down to its most essential features. This resulted in a truly minimum viable product that I could start using and learning from immediately.
What’s next?
As I reflect on this month-long project, I find myself at an interesting juncture. While I had initially considered moving on to a different project, I realize there's still valuable work to be done on this task manager. Currently, I use a simple markdown file for task management in my daily work. My goal now is to refine this app to a state where it can effectively replace that file, becoming a tool I actively use moving forward.
For the next month, I plan to focus on enhancing the web version, incorporating lessons learned from this initial development phase. Time permitting, I'll also begin planning a complementary mobile app version.
This project has been an invaluable learning experience in software craftsmanship, reshaping my approach to creation. While my long-term vision involves building a variety of projects beyond software and tackling more complex challenges, for now, I'm eager to continue honing my craft through this seemingly basic, yet personally significant, todo list.
To provide a more comprehensive view of this journey, I'd like to share some key artifacts from this stage of the process. These include the MVP specification (largely generated with ChatGPT's assistance), images of the Object-Oriented Design components, and Figma design mockups. These "Hard Artifacts" will hopefully satisfy the curious who want to see exactly what came out of this process.
Hard Artifacts:
https://docs.google.com/document/d/1Zo6OYo1HJFpsnjm66x_2ZEUJOoLNxYNg1OAG-WjffQQ/edit?usp=sharing