Last year I launched Lancerlist, an online platform that allows freelancers to promote themselves in their city and companies to find local freelancers.
I wrote an article about how I designed, built and launched the MVP (Minimum Viable Product) over a weekend, and this proved popular with designers, developers, and makers alike.
I thought I’d write a follow up piece about 5 higher-level concepts or approaches I practiced during the development process that helped me achieve the goal of launching the MVP over a weekend. Let’s get into it.
Define what success looks like
Before laying a single-pixel or writing a single line of code, I defined what success would look like in a minimum viable product trying to solve my problem. The problem, in this case, was ‘making local freelancers discoverable’.
I defined that success trying to solve that problem, would be freelancers seeing the value of the platform and sign up through their own free will. It would validate or invalidate the problem in the eyes of freelancers and prove the demand for a solution.
This influenced I approached the design phase, specifically, the landing page displayed all the cities current freelancers were from, thus providing a sense of social proof. It also influenced the sign up and onboarding flow, I wanted to make the act of signing up as frictionless as possible.
With such a specific focus I could cut out ideas I had because they did not help me achieve that goal, this ended up saving design and development time normally associated with bloated product scope.
The results of this were clear, 13% of unique visitors that hit the homepage ended up signing up and 92% of freelancers that signed up, completed their profile.
Keep it simple
Furthering from the first point, cutting out unnecessary features was a key factor in being able to design, build and launch the MVP over a weekend. When you start a new project, it is common to a million ideas and features that all sound great, this project was no different.
The method I use to cut out all non-essential features is to create a graph, on the Y axis, impact of feature and on the X axis, time to build. I then plotted all my ideas on the graph, from this I had a visual representation of my ideas and could discern which would have the most impact for time spent.
This method combined with my first concept, helps narrow the scope of the project down to a core feature or user flow. The benefits are similar, less time spent on designing and developing features that don’t impact the success of the project. Having a narrow scope also helps with writing copy and producing marketing materials as you an explicitly define the value your target users with receive.
For Lancerlist, the core feature I chose was the freelancer discovery flow. This would be the value proposition presented to users, providing the most impact on our defined success while being achievable in the time.
The effect of this was a simple discovery flow that allowed freelancers to be found through their city and then through their skillset. I could have made a more complex search algorithm but that would increase development time and not have a major impact on the success.
I then used the time/impact graph to create the projects roadmap, building more features in the months after launch.
Don’t reinvent the wheel
The development phase for Lancerlist took approximately 11 hours all in. How was this possible? I didn’t reinvent the god damn wheel.
By using the technology you know, you can apply the knowledge you’ve spent years learning directly towards building your solution, you’re not spending time learning the intricacies of a new language and the complications of deploying it.
Whether you’re building the project in PHP or Next.JS, you are trying to validate an idea, solve a problem, that is the purpose of an MVP. It can be tempting to use the latest fancy pants JavaScript framework but that won’t impact your success, there’s a time and place for that learning.
For Lancerlist, my technology stack was mainly based on Laravel, I’ve used it for years, I know the ins and outs of it. By using what I already have experience with, I could reuse code from other projects, this saved me a huge chunk of time that would elsewise be used following tutorials and fighting bugs.
I also used packages to speed up development, if something’s been done before, there’s likely a package that can help you. These packages are likely well tested, handle edge cases and are well documented, all help save you time and get you closer to the outcome you desire.
I don’t care what you use, code, no-code, it doesn’t matter, just don’t reinvent the wheel.
Reusable code
Another approach I took to the development was to consciously write code in a reusable way. In practice, this means creating a simple design system and componentising elements.
With Lancerlist, I created an extremely simple design system, I made a CSS variables file that had all the projects colours, spacing, type-scales, and grid systems defined. I could then use these variables throughout the application. This has multiple effects. It speeds up development as I don’t need to remember 10 different hex codes each time, I can just remember the variable name (e.g. $color-primary). It also improves the quality and consistency across the product, a heading on one page is the same size as a heading on another page. Simple stuff but worth mentioning.
I also componentised some of the common elements across the project, for example, buttons. By creating button components, the look, feel and functionality of a button is consistent across the whole product, providing a better user experience. This also speeds up development, every time I want a button, I can now just import the button, provide some parameters and we’re good to go instead of building from scratch each time. Another plus for components is if I choose to change the button design in the future, I only have to modify it once and it will be applied throughout the product.
By making a conscious effort to make common elements reusable, you can improve development speed, code quality, and user experience. Also, your future self with love you!
Repurpose tools you know
The last concept I used is similar to “don’t reinvent the wheel”, repurpose the tools you know, even if it’s for things they’re not designed for.
Any tool that takes less time to setup than it takes you to design and build is worth implementing. Need to send welcome emails? Setup a Zapier integration that watches for new users in your database and sends and email when it detects one. Need to do customer support? Hook up slack to handle requests in an interface you already know and love.
For Lancerlist, I added a list of the 1,000 most populous cities but I knew this wouldn’t cover everybody, instead of custom building a custom city selection feature I just added a button saying “City not here? Request it”, this opened up a Twitter intent, with the copy pre-written and a blank space where they could add the city. Was it elegant? Not really. Did it work? Absolutely! 100’s of people requested cities through this system.
It may not scale, it doesn’t need to, you can build a custom solution later once your idea has been validated and/or the tool becomes unmanageable.
Final thoughts
So, there we have it, these were a few of the approaches I used that helped me design, build and launch Lancerlist’s minimum viable product over a weekend. I hope some of these concepts can help you while you’re building your next product.
Agree or disagree with anything you’ve heard here? You can find me at @MadeByCrevans on Twitter.
This article was originally published on my blog at madebycrevans.com.
Lancerlist today has over 1,000 freelancers registered and thousands of people using the platform each month. If you’re curious, you can view it live at Lancerlist.co.
Top comments (5)
💯
Love this approach and follow a lot of this myself. Totally agree that when doing things like this is better to narrow down your features to only most valuable and release early. Validate the idea, test, and get feedback as soon as possible.
I work in a small startup company, we have clients for development services and now we are trying to create our own venture product. But its really annoying sometimes that our boss always think on the business side. Its like you need to create the "perfect" 1 million dollar application idea first before developing. I don't like the approach, so i give up giving ideas, and to just tell me what will be doing
A typical mid-size company should have a few thousand small ideas to bet on and explore in their market.
Most don’t, and want to plan, prioritise and fund just a few, resulting in big ideas with big budgets and big timescales.
Great article Chris! I've got a couple of ideas I want to push out but never get enough time to focus on it.
Knowing it can be done in a weekend, and tips for doing it, is really helpful.