The Developer‘s Workflow in Practice: How We Built our MVP in 30 Days

As a full-stack web developer, one of the most exciting yet daunting aspects of starting a new project is making all the initial decisions that will shape the application. From the technical architecture to the user interface design to the development process itself, these early choices lay the foundation for everything to come.

I want to pull back the curtain on how our two-person team at AlloAnim, a web app to help the City of Paris find available after-school staff, navigated this process and successfully launched a minimum viable product (MVP) in our first 30 days of development. Through a combination of agile practices, smart tooling choices, and an iterative approach, we were able to validate our concept with real users and deliver a polished initial product extremely quickly.

The Rise of Agile Development

Before diving into the specifics of our journey, it‘s worth noting that our approach was deeply rooted in agile development principles. While the term "agile" has become a bit of a buzzword, its impact on the software industry can‘t be overstated.

The 2020 State of Agile report from Digital.ai found that 95% of respondents‘ organizations practice agile development methods. Compared to the mere 37% adoption in their initial 2006 report, it‘s clear that agile has become the default way software teams operate.

And it‘s not hard to see why. That same 2020 report found that adopting agile:

• Accelerated software delivery (71%)
• Enhanced ability to manage changing priorities (63%)
• Increased team productivity (51%)

For a small team like ours, the ability to move fast and adapt to user feedback was essential. By embracing an agile mindset from the start, we set ourselves up to reap these benefits even with limited resources.

Project Context and Technical Stack

To set the stage, AlloAnim aims to allow after-school employees to easily create profiles with their availability. This enables the City of Paris to have a real-time view into their staffing options. The product owner, Christian Bockarie, conceived of the idea based on pain points he encountered while working as after-school staff himself.

As the sole developer, I was tasked with building out this vision in a short 5-month runway. On the backend, we chose Ruby on Rails as our API framework. While Node.js options like Express have gained popularity in recent years, Rails‘ maturity and strong conventions made it an easy choice for fast, reliable development.

For the frontend, "vanilla" JavaScript was the clear choice to start. While we planned to eventually integrate a framework like React, sticking to plain JS initially allowed us maximum flexibility as we sussed out the UI requirements. This approach of choosing "boring" technology let us ship quickly without gambling on shiny but unproven tools.

// Simplified architecture diagram
    +-----------------+
    |     Browser     |
    +-----------------+
             |
             | JSON over HTTP
             |
    +-----------------+
    |    Rails API    |
    +-----------------+
             |
             | SQL
             |
    +-----------------+
    |     Postgres    |
    +-----------------+

Capturing Requirements as User Stories

With our technical foundation in place, we were ready to flesh out the actual functionality of our application. But rather than diving straight into coding, we took a step back to understand the needs of our users.

We sat down with the head of after-school staff at a local school to understand her workflow and the challenges she faced with the current system. This conversation not only validated demand for our product, it clarified the essential feature set for an MVP that would provide tangible value from day one.

We captured these feature ideas as user stories, concise descriptions of functionality from the perspective of a particular user. User stories typically follow a simple template:

As a [type of user], I want [some goal] so that [some reason].

For example, one of our initial stories was:

As a member of after-school staff, I can create a profile with my personal information so that I can make myself discoverable for open shifts.

User stories provide several benefits over traditional software requirement docs:

• They keep the focus on the user‘s experience rather than technical implementation
• They can be estimated and prioritized to guide iterative development
• They encourage collaboration between developers, designers and stakeholders

With a backlog of user stories in hand, we were able to have meaningful discussions about priority and plan out our MVP sprint.

Mapping Out the MVP with Story Mapping

To translate our user stories into an actionable development plan, we turned to story mapping. Story mapping is a visual exercise to arrange user stories into a useful model to understand the system‘s overarching functionality.

Here‘s a simplified overview of our story mapping process:

1. We started by identifying the major user activities or goals that made up the backbone of our product, like "Manage profile", "View available shifts", etc.
2. Below each activity, we arranged the user stories that comprised the specific steps and details required to fulfill that larger goal. These formed the "ribs" to the backbone.
3. Finally, we drew a horizontal line across the map to designate which stories were essential for our MVP and which could wait for later iterations.

This visual representation made it easy for both the product and development side to align on exactly what we were building and why. It also exposed dependencies and uncovered holes in our thinking early, allowing us to adapt quickly.

Tracking Progress with a Task Board

With our MVP stories locked, it was time to shift into execution mode. To keep our momentum and hold ourselves accountable, we implemented a Kanban-style task board.

Each story was represented by a card that progressed through the following columns:

• Backlog: The full list of prioritized stories
• Ready: Stories that had been fleshed out and were ready to be worked on
• In Progress: Stories currently being developed
• In Review: Stories waiting for design/code review and testing
• Done: Completed, shipped stories

We held a brief stand-up meeting each morning to discuss the status of in-progress stories, surface blockers, and assign new stories from the backlog. This daily sync kept us on the same page and provided a built-in opportunity to re-prioritize as new information emerged.

Iterative Design & Development

With development underway, we shifted our focus to crafting the user interface. Rather than aiming for pixel perfection right out the gate, we took an iterative approach guided by just-in-time design.

To quickly establish a shared aesthetic, I created a mood board of UI inspiration from similar products. Using tools like Adobe Color, I was able to quickly experiment with different palettes to capture the desired tone.

With a general visual direction locked, I moved into translating the stories into rough wireframes. These low-fidelity mockups focused on the core content and user flows without getting bogged down in minute stylistic decisions.

As the wireframes took shape, I began implementing them in code, starting with a static HTML/CSS prototype. This allowed me to rapidly iterate on the layout and interaction details while the backend API was still in flux.

To keep design and development in sync, we leaned heavily on Zeplin, a tool that automatically generates style guides and assets from Sketch files. By integrating this into our workflow, I could easily reference the latest design specs without disrupting my coding flow.

As features were implemented, they were pushed to a staging environment for real-world testing and stakeholder feedback. We used tools like FullStory to record user sessions and identify areas of confusion or friction.

For example, early user tests revealed that the staff onboarding flow had a high drop-off rate. By analyzing the session replays, we identified that the date input for selecting their availability was confusing users. A quick iteration to replace it with a more intuitive calendar picker increased completion rates by 25%.

This tight feedback loop between design, development, and real user testing allowed us to arrive at a highly refined MVP experience in a fraction of the time of a traditional waterfall process.

Shipping Early and Often

Throughout the development process, we maintained a continuous deployment pipeline to make shipping to production as frictionless as possible. Each time a feature branch passed its automated test suite and was merged into master, it was auto-deployed via Heroku Pipelines.

This commitment to putting working code in front of users early and often was crucial to our ability to launch our MVP in just 30 days. By the end of our initial sprint, our production environment had already logged:

• 6,148 lines of code across 93 files
• 284 commits from 4 contributors
• 76% test coverage (aiming for 100% is unrealistic for an early-stage product)

But more important than the code output were the insights we gained from real-world usage. Each round of user feedback uncovered new edge cases and opportunities to improve the experience.

For instance, many staff members requested the ability to set recurring weekly availability instead of adding their hours individually each week. Based on this insight, we adjusted our data model to allow for repeating time slots and updated the UI to support this workflow.

This kind of rapid iteration based on live user feedback is the heart of agile development. By optimizing for shipping quickly over premature perfection, we were able to validate our riskiest assumptions and double down on what was resonating with users.

Learnings & Takeaways

Shipping an MVP in 30 days was an intense but immensely rewarding experience. More than any one technical decision or design detail, I credit our success to the agile philosophies we embraced from day one:

• User-centric requirements: Framing our work around user stories kept us laser-focused on delivering actual value, not just shipping code.
• Collaborative planning: Involving the whole team in story mapping and sprint planning created a shared understanding of what we were building and why.
• Continuous delivery: Deploying working code to users early and often allowed us to validate ideas and gather real-world feedback to guide our iterations.
• Design & dev in tandem: By parallelizing design and development, we were able to surface integration issues early and arrive at a more polished end product.
• Embrace flexibility: Agile is not about rigid adherence to a process, but rather a mindset of adaptability. By staying open to change, we were able to navigate roadblocks and seize opportunities as they emerged.

Of course, the journey was not without its challenges. As the sole developer on the project, I frequently found myself context switching between frontend and backend tasks, which could disrupt my flow. In hindsight, bringing on a dedicated frontend developer earlier would have allowed for greater parallelization and smoother handoffs.

I also learned the importance of regularizing communication with non-technical stakeholders. While the development team was bought into the agile process, it took some education and expectation setting to get our partners comfortable with the iterative nature of our work.

Establishing a bi-weekly demo cadence helped keep everyone aligned on our progress and provided a forum to solicit feedback and course-correct as needed. In an agile context, a stakeholder‘s role shifts from an approver to an active collaborator, and that requires a mental shift for everyone involved.

Conclusion

Launching an MVP in 30 days is an ambitious goal for any team, but with the right process and mindset, it‘s very much within reach. By front-loading our planning with user research and story mapping, optimizing for rapid feedback with continuous delivery, and fostering tight collaboration between design and development, we were able to go from concept to live product in just a few short sprints.

But shipping that first iteration is just the beginning. The real magic of agile development reveals itself in the subsequent cycles of learning and refinement. Armed with real user data and feedback, we‘re able to iterate with confidence and continuously deliver value to our user base.

The road from MVP to mature product is a long one, but by staying committed to the principles of agile development, I‘m confident we‘ll navigate it successfully. If you‘re embarking on a new software project, I encourage you to give agile a shot. Embrace the principles of collaboration, iteration, and adaptability, and you too can ship better products faster.

If you found this peek behind the scenes of our development process helpful, let me know on Twitter. And if you‘re curious to check out AlloAnim for yourself, head over to alloanim.futur.paris (just go easy on it – it‘s still an MVP after all). As always, we welcome any and all feedback.

Happy shipping!

Further Reading & Resources

• The 2020 State of Agile Report
• User Stories
• Story Mapping
• Adobe Color
• Sketch & Zeplin for design handoff
• FullStory for session recording and heatmaps
• Heroku Pipelines for continuous deployment