Forem: Chris Evans

My Side Project Stack 2021 - Tools and Technologies I Use to Bring Ideas to Life

Chris Evans — Sun, 03 Jan 2021 05:08:59 +0000

Introduction

Hello DEV.to! This is an article originally posted on my personal blog and thought it might be useful to people here.

I love and spend a lot of time building side projects. I use side projects to bring ideas into the world, learn new technologies and generally scratch my creative itch.

Throughout my years of building side projects, I’ve tried and tested a lot of tools and technologies, finding my favourites and building a broad knowledge of what can be achieved with each.

When deciding on what tools and technologies I use for a project, I must first determine what I’m trying to achieve with that particular project. I’ll talk more about that decision-making process in a future article, but for the sake of simplicity, the stack below is targeted towards bringing ideas to life, at the highest quality, in the least amount of time.

These projects are not my day job (yet), therefore finding the right time balance is important.

Let’s get into it.

Project Management

Notion Notion Notion. I use Notion for all my side-project-management. In brief, I’ve created pages to store ideas, timelines to manage deadlines and kanban boards to manage individual tasks, per project.

In the past, I used multiple tools, a notebook for ideas, calendars for deadlines and Trello for tasks. Bringing it all under one roof has helped me create a single source of truth, which is invaluable when managing multiple projects synchronously.

UX

I use three tools for managing the User Experience stage of my projects.

Up first is Draw.io, now renamed to Diagrams.net. It’s a simple diagram drawing tool. I use this to map out user flows, database schemas and marketing flywheels.

Any kind of user research lives in Miro. I used to use Notion for this but found the ability to move, group and link between content in Miro better suited my way of information association. It’s kind of like the crazy detective wall, with images, text, post-it notes and string linking information together.

To create and test UX flows, I use Balsamiq. It’s an interface drawing tool, but in a graphical style that lets you focus on the content and flow, rather than typography, colours and other UI elements. I will export my flows as linked PDF’s if and when they are needed for testing.

UI

For User Interface design I use Figma. Having my design files accessible everywhere, without having to move files between computers is a huge benefit. It also allows for real-time, collaborative editing, which is great when working with other people.

To supplement this, I use Google Fonts and Adobe Fonts for typography, Noun Project and Nucleo for icons, and Dribbble for inspiration.

Backend

I’m not a backend developer, but I do understand enough to get by. That may be an understatement, I’ll let you be the judge!

Generally speaking, I will use Laravel or CraftCMS as my main framework, Github for version control, DigitalOcean for hosting, Laravel Forge and Laravel Envoyer for deployment, MySQL for databases, and AWS for storage and email.

In the past year, I have been experimenting with Serverless and InertiaJS enough to feel comfortable implementing them into a project, as and when they are required.

Frontend

This year I’ve become experienced enough with React, Gatsby and Nuxt.js to have any one of them become my go-to frontend framework. However, I’ve realised these frameworks only need to be implemented when the complexity of interactions in the frontend requires particular structures.

My actual go-to frameworks are the server-rendered templating languages included within the backend framework, like Blade or Twig, combined with individual Vue.js components for more complex features. I know Vue.js like the back of my hand and the lightweight nature of the framework is great for optimisation.

I also use TailwindCSS, a utility-first CSS framework, to help bring the frontend to life. I combine this with BEM styled SASS for more complex CSS. After the UI stage of my projects, I will convert design system elements, such as design tokens, into the TailwindCSS config. The effect of this is more consistent frontends, that are written more efficiently, in a well-documented language that any future developer could reference.

Other frontend tools I use are Laravel Mix or Gulp for compiling, BrowserStack for testing and IntelliJ IDEs (PhpStorm/WebStorm) for development.

Marketing

My marketing stack is incredibly simple.

For email, I use Sendy, a self-hosted email service, to collect emails for various lists. I love Sendy because you pay once for the software and it connects to Amazon SES, meaning after the initial payment, you only pay for what you send, which on SES, is peanuts. It also allows me to create unlimited lists, set up autoresponders and view simple analytics, at no extra cost.

I have also started using no-code tools Zapier and Integromat in the daily running of my projects to automate simple tasks. This could be generating Tweets or moving emails across lists.

For some of the side-projects I use social scheduling tools like Buffer, this allows me to create a bunch of content up-front and release it over a month. Not being my day job, this is a great way for me to be consistent.

Final thoughts

There we have it, my maker stack going into 2021.

If you have any questions, feel free to get in touch with me on Twitter at @MadeByCrevans.

5 approaches that helped me launch an MVP in a weekend

Chris Evans — Sun, 16 Feb 2020 11:06:17 +0000

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.

16 Hours to launch — A breakdown of how I designed, built and launched a product over a weekend.

Chris Evans — Thu, 03 Oct 2019 10:03:45 +0000

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.