Earlier this year, I launched a side project of mine called Lancerlist which is a platform that allows companies to find freelancers in their city.

This launch marks an important milestone in my journey as a creative. It’s the first time I’ve taken an idea to launch over a weekend, 16 hours of working time to be exact.

In comparison, my first side project, a marketplace for influencers to sell Instagram shoutouts, took about 6 months to build and kinda flopped. Since then I’ve realised the value in getting an idea out there quickly to see if it’s worth pursuing deeper.

Below I’ve broken down those 16 hours into different stages and explained a little of what I did in that time.

Background

A while ago I was listening to a podcast about building vertical networking platforms, this particular industry was oil and gas, but what interested me was this network facilitated the majority of connections between rig owners and contractors.

In the creative freelancing industry, we have networks such as Freelancer.com and Elance that connect and facilitate transactions between companies and freelancers.

There are a few issues with these platforms such as the up to 20% commission these platforms take on each transaction or the global competition that drives down prices and causes a race to the bottom effect.

In the future I see both freelancers and companies wanting to take control more of the process. With the increase in global competition, the benefits of working locally will become more important; communication, reputation and quality control are all factors.

Idea and Scope (1 hour)

With this background information in mind, the main problem currently is discovery for companies and exposure for freelancers.

At the moment, discovery options include the freelancing platforms already mentioned or general networking networks such as LinkedIn. The problem with both is the results are too general. The freelancing platforms, while targeted, provide a global set of results. LinkedIn on the other hand can be filtered down, yet the results are not targeted towards freelancers actively looking for work.

Established freelancers have their network, reputation and existing clients to keep the cash flowing, entry-level freelancers have a harder time establishing these in the early days and current options require creating a personal brand (Twitter) or cold outreach (Email).

My solution to this is a simple platform that allows freelancers to sign up, display their contact information and selected pieces of work, and set their location. Companies can then search through locations, ideally their own, to find and contact freelancers based on the merits of their work.

Once this idea was bouncing around in my head I brainstormed a huge list of potential features and interactions that I thought would benefit the platform.

I then sorted these features by size (design and development time) and potential impact. I plotted them on a graph and created a roadmap with the high impact, low size items prioritised for the minimum viable product.

UX Design (1 hour)

For large projects, I would usually do in-depth user research, create personas and make journey maps. For a small project like this where the aim was launching an MVP quickly, these didn’t really matter because as an occasional freelancer I knew the target user.

I, therefore, decided the UX stage would be used to define the information architecture and create a low fidelity mockup the key flows of the product.

Information architecture is simply laying out what information/data is needed for the product to function and then organising it to show the relationship between the information.

Honestly, you could create the information architecture with crayon on a wall, I wouldn’t recommend it though if you want your security deposit back. What I mean to say is you don’t need anything special, I personally use a tool called draw.io, it’s a free, cloud-based, flowchart maker and helps me visualise ideas from my brain in a more permanent way.

Low fidelity mockups are a simple visual representation of the product, think sketching out screen designs on paper. In this stage I would take the information architecture and create basic layouts from it, thinking about how the user would navigate from screen to screen.

One of my favourite tools, apart from pencil and paper, for creating simple mockups, is Balsamiq. Balsamiq, with its sketch-like style, allows me to create simple layouts without having to worry about the finer details that come with UI design. I can then add links between the screens to create a clickable prototype, it’s basic but gets the job done.

UI Design (2 hours)

I now had a rough design of what I wanted to build, it was time to turn that into what the final product would look like. These designs are what I would base the frontend development on.

My weapon of choice is Figma, it allows me to switch between Mac and Windows with all the files stored in the cloud, meaning I can easily pick up designs where I left them, without worrying about if I have the latest version.

The first thing I sorted was branding, for the colour scheme I was loosely inspired by newspapers such as the Financial Times with their off white background and largely monochromatic colour palette.

The most simple logo I came up with was ‘Lancerlist’ in a serif that I liked with no icon, this could come later and wasn’t necessary for the MVP.

On to the actual UI, with large scale projects, I would usually create a design system, make all the components interchangeable and create an interactive prototype.

This wasn’t necessary for a project of this size, over the two hours I spent on the user interface I trial and errored many component designs, using Dribbble for inspiration when needed, and stopped when it was ‘good enough’, not when it was perfect. Very wabi-sabi.

I end up designing five full screens from the UX which covered 95% of the interface, I was happy to proceed to development.

Backend (2 hours)

To kick off development, I always tend to build the backend of the project first. This allows me to build the functionality of the product first and is usually the stage when I catch most of my mistakes from the design stage.

The first thing I did was set up two databases, a staging database and a production database. This allows me to test the product locally without the threat of accidentally deleting actual user data.

The whole of the backend of the product is built in Laravel, which is a Model-View-Controller (MVC) PHP framework. I’ve been using Laravel for years and love it, this meant I was saving time by applying my past knowledge.

Generally, the backend structure was the same as the default Laravel setup. I utilised Laravel Auth to create the authentication system, this literally took 30 seconds to set up and works like a treat, especially for the MVP.

Frontend (8 hours)

The most significant time expense in this project was the frontend development, turning the UI design into a functional, interactive and responsive interface.

For most of my side projects, I use VueJs as my main frontend framework and structure the frontend to work with Vue components. This does, however, add complexity and development time to the project and I’m trying to complete over a weekend, so I decided to keep the frontend simple.

For the HTML I decided to use Laravel’s Blade templating system, for those familiar with Twig it’s very similar but with the added benefit of being able to access Laravel functions. The HTML structure was simple, one layout that individual pages extend and pass properties, such as the page title, back to.

For styling, I again enlisted the help of another Laravel feature, Mix. Mix acts as a compiler for SCSS and JavaScript and is built into the Framework meaning there was no complex WebPack setup. All the styling was done in SCSS, structured with components, variables and mixins that keep the project organised, allowing for rapid development.

For interactivity, I used pure ES6 JavaScript functions that detect interactive components on page load and assign all their functionality on the spot. Generally, the interactivity at the MVP stage was minimal, as designed, so didn’t take very long to add.

Once done, I hooked it up to the backend to pull through live data and tested it thoroughly, checking for any flaws in my logic or bugs in my code and fixed them accordingly.

Deployment (1 hour)

The project was now ready for launch, but at this stage, it only lived on my local computer, it was time to move it online.

The first thing I did was create a git repository and push my code up there. This allows me to control different versions of my code so I can work on and release multiple features at a time.

I then set up a basic DigitalOcean droplet (server) with the help of Laravel Forge, a tool that provides a user interface for managing Ubuntu-based servers.

I then bought the domain, set up the appropriate DNS records that point to my server and created a new project for the domain in Forge. From Forge I then setup deployment which takes the code stored in the git repository and copies it across to my server.

I proceeded to set up a new database in Forge and copy across the database from my local computer.

The DNS records propagated about 30 minutes later and we were in business. The project was now up and working from the live domain.
Job done.

Launch (1 hour)

Launch time! In the past, I’ve held back on launching projects, either due to trying to make the project perfect or anxiety about putting my work out there, not this time.

I decided that the launch operation would be fought on two fronts, Twitter and ProductHunt, so I concentrated my preparation around these.
For Twitter, I set up the account, branded it with a profile picture, primary colour (when they were a thing) and call to action in the bio for those curious. I created social media cards for the website and made a pinned tweet with the call to action and link.

For ProductHunt I prepared for launch by creating thumbnails, taking screenshots and pre-writing the first comment which targeted user engagement. I then scheduled the launch through the ProductHunt dashboard for the next day.

I built a very basic, password-protected dashboard (as a new Laravel project) that measured page views and sign-ups, and deployed it to a subdomain so I could measure the launch when I was on the move.
The next day it launched.

You can find the 280 character summary of the launch aftermath over here. At some point, I’ll write another article going into the stats of the launch.

But to give you a flavour of what happened, I launched it at midnight while on a redeye coach to Cornwall for a spot of surfing, 18 hours later I was sat in a Wetherspoons doing customer support!

Check out the project live at lancerlist.co.
You can find me and follow my progress on Twitter at @madebycrevans.

Originally published at https://madebycrevans.com.