The Curse of the Spreadsheets
I have been running a lawn care service since I was twelve, creatively called C's Lawn Service (because my name starts with a 'c'). When I first started this service I was essentially managing the entire operation with spreadsheets. I had a spreadsheet for invoices, a spreadsheet for customers and their information, a spreadsheet full of discount codes and so on. I must have been going through a phase at the time where I had just discovered the utility of spreadsheets and office software, clinged to them and wanted to use them for everything, as my autistic-like interest patterns often make me do. Even though I did not know of many “power-user” features in spreadsheets, such as formulas or hosting multiple sheets within a single document file, this worked in the fact that I could manage the company's operations successfully. I could at least store information in the documents, which was the most basic of needs I was originally after. However, this system presented a major problem in terms of scalability (although at this time I probably didn’t associate any meaningful definition with the world “scalability” in a business sense); It took a considerable amount of time to do even simple, repetitive, tedious tasks. To add a customer in the list, even, was a task one would shy away from once any company using it got past 50 or so customers, since the entries would have to be shifted around manually in order to make the list alphabetical (at the time I also did not know that there was such a thing as the automatic sorting of rows in a spreadsheet).
The system was so inefficient that it was practically an exercise to test my mental stamina every time I had to do a batch of invoices. I didn't have an emailing system at the time due to my lack of automation and the fact I had hardly any of my customers’ emails, so to send an invoice, I had to print out the invoice template (which was from a free template I downloaded off the internet - yet another spreadsheet file I had modified with my logo and other branding), write by hand what was done and how much it cost (which was usually all in memory since I had few enough customers I could do such a thing), fold it up, put it in a branded envelope, write their address on it and go out and hand deliver them. This happened for every single customer, every single week (it would have been too difficult to do cumulative monthly billing due to the nature of the whole situation, and my not so strictly enforced, but still existent payment terms of "Net 30 (days)" after a service’s completion).
Yardbook
Due to the annoyance of having to go through this process every time I needed to bill my customers, I gained an increasingly accelerated desire to automate the process of keeping track of customers, services and invoicing. There was just one problem: I knew nothing about programming at the time. I was too young, inexperienced and unwise. I did not have any clue that, even using the same methods I had already been using involving spreadsheets, that there might have been a more efficient way to manage the business. I had no idea about software or data analysis, marketing and efficient procedures. I did not understand how to lead my business in a direction able to grow steadily and worth scaling. But with the knowledge I did have, and the desire for less tedious invoicing, it was then that I searched for an alternative. I ended up finding a website called Yardbook, which claimed to do exactly the tasks I was looking for, plus many other features that I had not even thought of (which may have served as inspiration for some other business ideas at the same time);
It had a page where you would import or add in all of your customers, even to go so far as to record how much mulch their yard needed and how big their lawn was. It would automatically keep track of your scheduled services and their prices, create invoices from them with no hassle, and most attractive to me, send them to the customer via an email, powered by their own mailing relay (as I had no clue how to set one up myself).
Once I had gone around and collected the uncompleted contact information of all my customers at the time, I set off typing all their information into Yardbook and used this system for approximately one year. It was a great improvement from my old folder of spreadsheets and cut back on my invoicing time considerably. However, it was still not entirely catered to my liking. First and foremost, it wasn’t branded enough. Actually, it was branded too much, but not with my logo – rather, it posted the Yardbook logo on all emails sent to the customer. And, the domain of which the emails were sent from was “yardbook.com” and not “cslawnservice.com” like I wanted. Replying to them also would result in an error instead of starting a customer service ticket, something I am now thinking of incorporating into UltiScape. Now, the first issue could have been prevented had I paid the monthly “Software as a Service” fee, but even then it would not have changed the domain, and I generally didn’t like the idea of paying for the software. I also essentially wanted a system I could customize not just the looks of, but the function. If I wanted to add in more types of data collection, such as the number of bushes in their yard, rather than just mulch and lawn size, I couldn’t. I didn’t have authority over their development team and I didn’t have the source code to change it myself. Basically, it wasn’t mine.
It was someone else’s software, hosted on someone else’s servers, using someone else’s domain and boasting someone else’s logo. Being the independent person I naturally am, I was not a fan of this. I didn’t want to rely upon this service continuing to exist in order for my business to flourish. I was a purist - I wanted to rely on me making my business flourish, in my way, so I knew why and how it was flourishing to as detailed a level as possible. And if it wasn’t flourishing, I had data to analyze and tools to improve my operation to get it back on it’s feet.
My Web Development Awakening
Early in the year I had begun to learn how to create websites. The first website I had created was actually a stationary, presentation website for C’s Lawn Service, accessed by the free “cslawnservice.tk” domain and contained an embedded service catalog PDF and links for customers to search for their invoices on Yardbook. I had made this static site using Adobe Muse, as I, despite having interest in making websites, had not yet taken the leap into writing my own code. I didn’t even understand HTML, and likely didn’t have time to learn all that was involved with web development considering everything that was going on in 7th grade.
As discussed in a previous post, when I was around this age, I was heavily interested in Minecraft. Anything Minecraft related, you could ask me about it and I could tell you 10 things about the thing you asked me about. I would come home every day and practically all I would do, apart from the homework I partially completed and often forgot about, was play on my prized possession, constantly backed-up, self-hosted Minecraft server, CamCraft, along with a few friends and acquaintances who did the same. Minecraft was like a second life to me. We had built a city, houses, shops and essentially an entire functioning society, complete with economy and government, all within the virtual world of CamCraft.
But at some point, I took some time away from my server to do something other than Minecraft: Make a website for CamCraft. The site boasted news articles written by players about virtual events and statistics on each player which were gathered by a plugin I had found and sent to a MySQL database. In fact, this site still somehow still works and can be found here. According to the statistics on my profile, I apparently spent over 1,482 hours playing this game.
Think of the ways all that time could have been used more productively. I could have been helping the world get closer to ending world hunger, but no, I was playing Minecraft...oh well. On second thought, playing a game I paid for on a computer I paid for on a desk I paid for using electricity I’m paying for is paying for the salaries of, and employing, the people producing those things, who use it to pay for food, so I suppose I actually was helping to end world hunger...hooray! Humor (and perhaps some seriousness) aside, I might not have gotten into web development if it was not for that game. Learning about HTML, PHP and SQL servers opened up so many ideas to me about improving my business operations.
Finally, a Custom Backend!
After making this site, I was excited to see my new ideas come to life. I wanted to get right to work on another site. I knew I needed a new website for the lawn service since I wanted a more personalized backend, and I also just simply wanted to test my new knowledge. So I did. I spent about a month or so putting together what I thought was a huge project. It would manage customer info, estimates, invoices, schedule recurring jobs, and send emails.
This new site has some issues though. The email system did not work super well, as sometimes the messages would trigger my customers' spam filters and they would complain about not getting the invoices. But it wasn't too bad, and once I got removed from some blacklists this mostly stopped happening. For the 20 people I was managing, too, it wasn't super noticeable and I could easily deal with the few customers who it affected. It also could not do batch/template mailing for marketing/notice blasts, and I had not yet learned any asynchronous server-side languages so it was all done using procedural PHP called from AJAX. I also had left out a few features that could have been useful, like editing a customer's email or phone number after I had put them in the system, and editing a job's scheduling presented quite a bit of a challenge that I suppose I didn't have enough data architecture or programming expertise to execute effectively.
Despite these issues, I used this site successfully for a few years. I used a third party service for email blasts (which I was not a fan of but I didn't have an alternative) It wasn't until in 2019, I had an 'interest burst' back to web development. I wanted to learn a few more things and I knew I was going to want a more professional backend for managing my service business.
UltiScape
It was after using the previous site for all my time running C's Lawn Service that I wanted to incorporate my higher level of programming expertise, data modeling skills and my desire to learn more advanced web development that I decided to make yet another backend for managing landscaping businesses. I was searching around for names and came up with the name "UltiScape". It sounded good, was decent enough at self-describing that it's an app for landscaping, and the domain was available!
I started with creating a database model for all the data needed to manage the features of the site. The site runs on simple MySQL and has around 80 data nodes.
Then is where some naivety stepped in. I didn't know anything about using web frameworks so I was developing it all with plain PHP from scratch...and I didn't yet know that ORM (object relational mapping) was a thing that people used commonly and that frameworks to do it already existed. But, with all my brilliance, I came up with the "amazing new idea" (to me) to create a class for each data node since that seemed to make working with the data easier. Well, I spent probably about a month just writing class after class for the 80 or so tables in this database...by hand. Fast forwarding to today, when I know how to use sequelize-auto with JavaScript or other equivalent tools, this seems like a waste of time, but at the time I had no idea that there was a better way of doing it.
And I kept on developing this site in plain PHP. Each new page took quite some time to get going, since there was so much repeated code everywhere. It was much cleaner than some of my previous sites, but still not something that any major development team would want in their codebase. So, I started to learn about newer web technology that might further my knowledge and make me a little more employable on anything other than my own projects. And that led me to where I am now, porting UltiScape to run in NodeJS instead of PHP. This provides much more flexibility in terms of asynchronous scheduling of tasks, easier integration with common frameworks, less repeated code, and one my favorite changes: being able to run things on the server without action from the user or cron jobs. It also lets me use a better ORM library that made models for my database in about 10 seconds instead of a month.
This port away from PHP was certainly not a requirement. I could have just kept developing it with my old ways, released it and it would have worked. But at this early point in my development career, I figured that UltiScape's completion could wait if it meant I could use it to learn some new concepts. I am learning NodeJS, Express.js, templating engines, and most importantly React.js. Yes, UltiScape's frontend will be using React.js from now on. And, what does this mean? It means I'm finally learning how to develop a site with two completely independent parts - the backend and the frontend. This is different compared to my old PHP development where the backend rendered the final HTML response of the entire page on every single website load, and every single page change. This not only put a lot of stress on the backend and slowed the site down, but also made it a lot more difficult to make changes to DOM elements without a reload. It was a big mix of backend rendering being then edited further by the browser JavaScript. That all is changing now that I am using React. It sends all the UI code to the browser on the first load, and then every page change simply calls client-side code to alter the DOM. No need to reload the page and ask the server for more HTML. All the server has to do is provide authentication and data! Marvelous.
Have any thoughts about this project? Let me know in the comments below!