Introduction

This is the first post in a series that I plan on writing, which will cover the build and (hopefully!) launch of a project I’ve been working on lately – FleetReach.

The other day, I was working on a project when I suddenly realised I had absolutely zero interest in it; I was coding for the sake of coding. Now, there’s nothing inherently wrong with that, but I think one should have an interest in one’s own side projects.

It struck me that I really missed working on something that was close to my heart. Sailing and the water in general has been ingrained in me since I first got into a sailing boat aged 10. Building a product around the sailing/watersports industry sounded like a perfect match for me in 2015, and I think it still is.

I’m the kind of person who doesn’t deal well with MVPs - I tend to keep iterating on something until it’s ‘perfect’. In reality, that often means it takes me a really long time to ship something. It’s a trait that I’ve become aware of, so I’m hoping that writing this series as I go will help me stay accountable and encourage me to keep pushing forward, whilst staying aware of goals that I set myself.

Some context

FleetReach is a side project that I’ve dipped in and out of over the last 5 years.

The initial idea was basically an event-management platform, kinda like Eventbrite but for sailors - offering sailing-related features such as race scoring. Back then, most clubs scored their races using pen & paper or a certain piece of scoring software. I’m not going to name it here, but this software had the monopoly over the market - almost everyone used it. Why? It’s free and “everyone else uses it”. Unfortunately, it’s also only available on Windows.

Way back in 2015, I thought I’d found an opportunity so my usual partner in crime (Ben James) and I started prototyping on the first revision of FleetReach. We wanted the initial version to allow people to host and score events/races, run their clubs, track memberships and also see positions of vessels in real time.

We went a bit overboard with the initial setup of the project, opting to encorporate a company (FleetReach LTD) and assign ourselves as directors and shareholders. We learnt a heck of a lot about that whole process from doing it ourselves, but with hindsight I see that we were a fair bit ahead of ourselves. We should’ve focused on building an MVP and getting it out there for people to check out, rather than dedicating time to working out how to register a limited company. I don’t regret taking that approach though, it now gives me a great base to start from and we both learnt lots of things that we otherwise wouldn’t have.

Vessel trackers

Initially, we focused a lot of time on the vessel tracking system. This consisted of attempting to build a mesh network using 2.4GHz radios and Arduinos. We wanted to strap a device to every boat so our customers could track them in real time through a web interface. We thought this would have good selling points in terms of safety and security. We found that building this kind of system is actually incredibly difficult. First up, we had to figure out how to make a mesh network. Back then, there were extremely limited options for pre-built solutions and they were prohibitably expensive. So, we decided to do it ourselves. We bought some cheap radios and Arduinos from Ebay and Ben got the soldering iron out. We were expecting to be able to transmit and receive up to about 5km, but we were struggling to make it any more than a few metres.

We also needed to figure out how to make it waterproof, cache data if it failed to dispatch it (and track that on-device somehow??) and a host of other problems. It was a long time ago, but I think this was the point at which we gave up trying to make boat trackers and focused on our online product instead.

Version 1

FleetReach v1 was my first stab at developing something of this scale. With hindsight, I realise that I really didn’t have a clue what I was doing.

It was written in PHP, which happened to be what I was learning at the time and the frontend was written using Bootstrap v3. It was hooked up to a MySQL database and the whole thing was deployed in shared hosting with Godaddy.

Ben and I also used the server as a file store, because we had no other place for sharing files and didn’t want to pay for extra Dropbox storage 😆

There was no ORM and no framework of any kind. It was literally just vanilla PHP with raw SQL queries.

I say that, but the product did in fact work. I’m actually quite proud of myself for that - without any of the tools that I now use day-to-day and would say I can’t live without, I built a platform that actually worked. I won’t go over all the features it had, but the basics were user auth flows, club registration, event hosting/scoring, competitor registration and some more managerial tools such as membership management and the like.

Looking back through the code (yep, it’s still on GitLab), I can see numerous problems that I had no idea of back them. I’m quite glad it never got used, as the potential for SQL injection is… laughable. Hey ho, live and learn.

It was around that time that I discovered automated tests and started making quite good use of them. My favouite snippet that I’ve found so far is about the email tests. The system sent emails for various actions, such as a user registering for a race. I added a test for it, but it would appear that I didn’t bother (or know about) mocking the actual email-sending logic itself - every time I ran the tests, it would actually email me.

I remember pitching the initial version to someone at my local sailing club (somewhere I spent a lot of time over the years) and they were quite interested in it. So much so that the person in question started creating events and valuating whether it was suitable for the club to adopt. I didn’t know it then, but I made one of my first mistakes which I now avoid like the plague. They asked if I was willing to make changes to suit their use of the platform. With the prospect of real money in my mind, I didn’t hesitate and agreed straight away. If I was asked that question now, I would seriously consider it before answering. I’ve worked on a fair few systems which are bound by customer-specific features and those need to be supported forever, it’s no fun.

Sadly, the adoption didn’t go as well as I hoped. The customer found a few bugs with the system and directly asked me if it was production-ready and I remember agreeing that it was more in an alpha stage. I think this was the critical sentence that lead to their hopes and usage dropping off and it never really got off the ground after that.

I believe losing our first customer before we’d even started affected my resolve and confidence around the platform. After that, I slowed down on the development and eventually stopped altogether.

Version 2

Somewhere along the line, I discovered Node.js when working on a project with some mates. I decided this was what I needed! I could rewrite the whole FleetReach app in node and see boosts in…? Who cares! Let’s go! I think I partly jumped at Node.js because it was new and shiny, and because it gave me the much needed enhusiasm to get FleetReach going again.

I used Express as the backend with Handlebars for the views and, wait for it, MongoDB as the database. I had no idea what a relational database was, so I just did the foreign key management myself. I feel sorry for past-me, he really had his work cut out. At least I didn’t roll my own auth system this time, I went with Passport.js to save time.

This one even had CI/CD! I can’t quite remember how the deployment worked, but it probably just FTP’d files to a server, SSH’d in and restarted the pm2 service. Could be worse.

I used Mongoose as the ORM for the Mongo database, and this was my first experienc with an ORM. I remember realising how much easier it was straight away - no more writing complex SQL queries by hand (back then, I used phpMyAdmin a lot to write the queries).

My approach to models and schemas was pretty rudimentary as you can see below. Who needs a schema when you can just define it in the comments? Certainly not me.

I don’t have much memory of how far I got with the rebuild, but I think v2 supported most of the features of the v1 PHP app. It even took payments - users could pay to remove restrictions on the numbers of events they could create. That went through our payment provider - Braintree (a PayPal subsidiary).

I’m considering using Braintree for the new version of FleetReach as we already have an account setup with them - or should I use Stripe? Hit me up on Twitter if you have an opinion on that 😁

I got a few mates involved with the testing process this time, this was my attempt at building a community around the product. It actually kinda worked - a lot of my sailing mates were really interested in it and glad to help out. I figured they could be useful to help sell to other clubs too.

Sadly though, I never really completed v2 either. Other more exciting things started occupying more time, alongside less exciting things such as getting real jobs. I was doing some freelance web development for a while (mostly on small-scale Wordpress sites) and started teaching dinghy sailing, alongside lifeguarding at my local pool.

I also moved to New Zealand at the end of 2017 and this brought with it a whole load of other (good!) distractions.

These things all contributed to me loosing interest in version 2 as well, the last commit to the Node.js app repo was on March 23 2018.

Okay, why’re you telling me this?

There is still a gap in the market for a product like FleetReach. In 2015, there were no competitors - if I’d known what I was doing back then, I’m fairly confident that right now I’d have something with traction. There are a few more competitors now, but I think I know the niche of FleetReach fairly well.

There are people out there who want something like this and I know the amateur sailing industry quite well. I need to work on something that means something to me and this is the perfect opportunity to do just that. I’ve been working on a couple of Rails apps recently and I’ve wanted to make something from scratch with Rails, so that’s probably where I’ll start.

This is the first post in a series I plan on writing that will cover the build of FleetReach v3 (no, I’m not actually going to call it that). Like I said at the start of this post, there are a few reasons I want to cover my progress on the product.

• Accountability. Knowing that people have seen what I plan to do should give me a reason to actually do it and meet my own deadlines
• Building a community. As I found out, building a community of people around your product is really important and can really pay off. I think writing about what I’m doing on FleetReach, justifying the decisions I make and allowing people to track progress could really help me with this.
• Writing. I’ve neglected my blogging for a while now and I feel guilty about it. I enjoy writing and it’s a useful skill, so it’s something I should practice.
• Career development. There will come a time when I need a new job and seeing my process of building something should be pretty important to potential employers.

Alrighty, what’s next?

I’m gonna start coding. By the time you read this, I’ve probably decided on the stack and got an initial app up.

I think I’ll probably go with a Nuxt frontend deployed to Zeit Vercel backed by a Rails API app deployed to Heroku. The reasoning behind that stack is I know it fairly well and it should allow me to iterate quickly. I’m keen to keep changes small, focus on an MVP and get that shipped. Other features can take a back seat until they’re required.

I’m potentially going to do a mobile app (probably React Native) but I haven’t fully decided and that can probably wait until after the launch. I can assess how important a mobile app is after that, since it’ll be a fair amount of work.

I have a Slack workspace setup but I’m not going to open it up just yet. I’m probably going to deal with this on an ad-hoc basis - I’ve seen a lot of startups open up Slack spaces and I feel like it adds a lot of overhead and distractions which have a negative effect on your ability to ship code. Of course, if people are interested in chatting about FleetReach (or anything else) and/or helping, joining the community etc then let’s chat! My Twitter DMs are open or you can flick me an email on [email protected]

My plan is to get one of these posts out every two weeks, but that will 100% depend on what my schedule is like. I plan to detail what I’ve worked on and plan to work on, plus any breakthroughs, progress and setbacks. I’m quite busy with my real job and other projects, plus we’re heading towards the snow sports season here in NZ, so my weekends are likely to be occupied by snowboarding. That leaves fairly limited time for working on FleetReach, but I’m gonna see how we go!

Is there a deadline?

No. As this is currently a hobby project (although hopefully not forever), I don’t have anything resting on it’s success or any time-based constraints. As such, I’m deliberately not going to set a deadline and put trust in my dedication to get this done. A lot of folk will disagree with that and suggest that having a deadline forces you to get it done. To those people: sure, but why stress about a side project? 🤓 I may set myself deadline for certain features, but I’m not sure yet.

Wow. That’s a long post. I think I’ve covered everything I intended to. Hopefully the next post will be good to go in a couple of weeks and I’ve got lots of progress to share. In the meantime, I’ll get back to coding! Over and out ✌️