When introducing a new idea, product or service to a prospect, the phrase: "How open-minded
A few years ago, the MVP was all the rage. Put something out there… test… get people using the product… et cetera. MVP of course, stands for “Minimum Viable Product”, which basically means: "Let’s build something as quick as we can and get it out the door to test."
While I agree with some of these “MVP-esque” ideas, I don’t think they resonate with every software business. And, I don’t think they resonate with Sagenine—a software product for lawn maintenance and landscape companies.
Let me explain.
If you are building software your target customers will use to run their entire business, you better get it reallllly close to perfect on your first go. Because, if you don’t, your churn numbers will be off the charts, and it will take 10 times the effort to get that customer back.
With Sagenine, lawn and landscape companies will be able to run their entire business using the software. So, if you think about that statement, it means we need to build a lot of software before we go live.
There are four main parts to Sagenine:
- Basic CRM
- Secret Ingredient
What To Build First?
My cofounder and I decided to tackle the CRM (customer relationship management) portion first. It wasn't a hard choice. Basically, a user must be able to add an account to be able to do anything else. So, that decision was easy.
Second part was figuring out what components we needed to build.
The good this is, the color scheme, logo and basic app structure were already finished. So for this, we could simply focus on the CRM portion.
First thing we did was break the CRM project down into bite-sized pieces.
As an aside, this is the best way to build stuff... break it down. If I told you to build a CRM, you'd think: "How in the world would I do this?" The task is overwhelming.
But, if I told you to build an input box that will take an account name and persist it to a database on save... well then, that's way easier. Specific and small.
So that's what we did. We took a couple hours and broke the giant CRM task down into small, manageable pieces.
Next, we set-up a time frame of 6 weeks to complete all the tasks that make up the CRM feature.
By the way, 6 weeks is a nice time frame to build intense software features. It's not too long, and not too short. In addition, I think shorter sprints results in a ton of tech debt.
By staying with one feature for 6 weeks, you become extremely versed in the problem. I think it brings out the biggest gains.
The main objective in these 6 week sprints was to complete a major feature end-to-end. That means the feature is totally done. Rock-f-ing solid. Half-baked, half-finished features is not the goal.
How Should We Build Features?
I have always been a huge fan of pair programming. Two minds is always better than one... plus it's fun to work on stuff together.
Now, we both have full-time jobs. So we needed to designate time to work on Sagenine. We both work best in the morning, and decided 6:00 to 7:00 am would work best.
You might be thinking, "One hour is not enough time to build anything." And, for most developers, I would agree. However, we're both pretty good that this stuff, and 1 hour was enough time to get a lot done.
One hour of completely uninterrupted work produces some amazing results.
Why one hour? Well, we're not trying to rush this product. We decided early on that design and stability are the most important aspects of this software. In other words, it should be easy-to-use and just work!
Our objective with this business is not to work 80 hours per week. That's bullshit. We want a business that will last. A business that's fun to work on and in. The goal is to create excellent work, send if off to production, then get on to the next thing.
Working 80 hours per week is a sure fire method to create hatred and burnout. I promise you... working 80 hours per week on anything will only make you hate that thing.
Do yourself a favor and stop the madness.
What Did We Complete?
In 6 weeks we were able to complete the entire CRM portion of Sagenine.
Here's the Top Ten Features we Completed:
- All data persisting to a real backend–no mock data!
- Fully responsive interface. Tailwindcss is the bomb! More on this later.
- Vue.js and Vuex working perfectly.
- i18n fully implemented.
- Auto-translation fully implemented.
- Fully functioning search.
- Add accounts interacting with the "secret ingredient".
- Error handling.
- Automated production builds.
Did You Have Any Pain Points?
Of course. I think the biggest pain point was getting Prettier and ESLint to work with Vue.js and VS Code.
We finally turned both off. It was too much of a pain trying to fix bullshit errors like tabbing issues.
Also, Vue.js and Vuex have a pretty good learning curve. I'm super happy we're using these tools, as I think they are amazing. But, of course, we had to learn them.
Also, learning Tailwindcss took some time. But, now that I've got it, there's no looking back. Tailwind baby!
The next thing we're working on is the secret ingredient.