I had written my first Service Management System (SMS) for Humac back in 2008 and Servo was, in many ways the “2.0 version” of that. In true 2.0 fashion, getting it out the door proved to be orders of magnitude more difficult than I could ever have imagined.
What does it do?
Servo is basically an ERP for service providers. It will do everything except pay your bills and salaries. At the center, you have the service order which contains customer data, the serviceable device(s) and service parts, products and services you want to sell. From there on you can create a GSX repair and order any replacements straight from Apple without using the GSX web UI.
Each order belongs in a queue, which is sort of a “folder”, with quite a bit service-related intelligence added in. For example, each queue can contain any number of statuses, each with custom time limits. Each queue can have it's custom print templates and different users set to handle them.
Servo's inventory system supports separate stocks for service location as well as pricing info for exchange and stock parts, all easily updatable from GSX. You can also get notifications if a product drops below a certain threshold.
Multiple techs can be assigned to each case and users are automatically notified if someone else makes changes to their service case. Servo can send out emails as well as SMS messages (over a number of gateway protocols) and also read emails over IMAP.
Instead of a traditional flat customer table, we use a tree structure so you can define complex hierarchies in customer data. Customers can also create their own service orders with the built-in checkin interface.
You can also use Servo as your POS system - quickly create sales orders and dispatch stuff and we even support multiple payment options per dispatch.
For larger environments Servo also supports automated rules which allows you to trigger different actions based on changes in the system.
There's also a comprehensive stats system which shows you how many cases you're processing as well as how long stuff is taking, etc.
And of course, we also have the obligatory API which you can currently use to create and query cases. This part is constantly evolving as customers request new features.
If your service shop is still running on FileMaker, then do check it out. You can either download the source and follow the installation instructions, or download a complete, preconfigured VMWare virtual machine.
“Everything” is not a spec
Perhaps the biggest reason why Servo took as long as it did to release, was that for the longest time, our requirements specification was basically “it should do everything”. That is the stupidest approach ever and pretty much a guarantee that the project will crash and burn.
The name
Google defines a servo as:
a powered mechanism producing motion or forces at a higher level of energy than the input level, e.g. in the brakes and steering of large motor vehicles, especially where feedback is employed to make the control automatic.
… which is a perfect description of what the system is about. It's a smaller engine that drives something bigger. There was also an inside joke at Humac around this song by Martti Servo & Napanderit (but I digress).
So I had a great name, but what about a domain? The .com has been registered since 1995 and wasn't going anywhere. servo.org didn't have a website, but was registered to Mozilla. I actually contacted them about acquiring it, but the hostmaster kindly responded and it said it was reserver for “future projects”. About 18 months later we found out it was their browser project for Samsung.
So I went with servoapp.com and also registered the trademark for ServoApp. I wish had known that ServoApp.exe was also the name of some pretty common Windows malware. So that's why, to this day, if you google “servoapp”, you still get the malware results. Bummer.
The Logo
The logo was designed by Jan Kovarik. The same dude who designed the original icon set for Twitter's Bootstrap CSS framework. I really dig the logo and working with Jan was a pleasure. If you need a logo or some graphics work done, do check him out.
The stack
HSX (the system I wrote for Humac) was written in PHP and used my little framework which I had developed while working on some stuff in college (including a CMS I was selling back then). I didn't feel like maintaining that framework anymore and was looking for alternatives. PHP has no shortage of web frameworks, but they all sucked. Hard. My final hope fas ZendFramework which back then (before 2.0) actually sucked the most. I went through all major frameworks for all the major languages (Ruby on Rails, Node.js, PHP and Python).
Servo's PHP roots spawned gsxlib which is still my most popular Github repo. :-) I realise now that a big reason for why PHP web frameworks suck so hard is that PHP is itself already a web framework.
I settled on Django mainly because of their documentation, which back then was the best I had ever seen. I'm not crazy about Python as a language, but it works. PostgreSQL was the default DB for Django and it seemed good (even though I had no previous experience with it). At some point we had a working prototype using MongoDB, but that turned out to be too confusing.
In many ways, the timing proved the most influential factor here. In 2010, the web development scene was very much in flux (I mean ever more so than usual). Minimalist back-end frameworks were gaining traction (I'm looking at you, Node), as were “completely new” client-side libraries (esp. Backbone). Most of this was due to the client/server separation that was going on because of the whole mobile boom.
Django was at version 1.4 when Servo was first released and it's been quite a ride going through the updates. It's nice to see such a mature framework still being so nimble, but for enterprise software that can also be a bit of a curse. If you want more “best practices”-type documentation for your Django development, I can whole-heartedly recommend Two Scoops of Django by Two Scoops Press.
One really unpleasant surprise about Python was the shockingly poor state of it's SOAP libraries. GSX speaks SOAP which was so well supported in PHP's standard library that I just assumed Python's SOAP support was at least as good. After going through all the libraries, I had to actually write the SOAP implementation from scratch. Luckily, with the excellent lxml and requests that proved pretty easy.
Pricing
Servo costs 600 EUR/month. I came to this number by estimating the monthly income I need to live comfortably in Helsinki (about 6000.- EUR/month before taxes) and divided it by the estimated number of customer installations I could support well on my own (about 10).
There are several pros having a static pricing model:
- It's simple to sell. You can put the price on the website and that's that.
- You don't need “features” in your system to limit stuff (like number of users or orders or whatever) based on the “plan”
- It's simple to buy. The customer knows exactly how much they have to pay and costs are predictable.
- The more the customer uses the system and the bigger their service grows, the cheaper the system gets.
There are also several downsides:
- You will lose smaller customers thinking it's too expensive.
- Large customers will still think it's too cheap.
I think the static pricing model was a good move and I wouldn't change it. My mistake was maybe the “includes everything” approach where I would do all sorts of extra stuff (in addition to the initial setup) without any extra charge. Looking back, it would have been better to have a clear price list for additional services as well as different “support packs” for end-user support.
The Business
The company behind Servo is First Party Software LLC. It's registered in Estonia mainly because I was in a hurry (the whole process took about 4 hours from start to finish). The name actually came from a chat I had with dre years ago about starting a software company - First Party Software - “First Party, then Software”. :-)
My starting capital was my severance check from mcare and the money I got from selling my drum set. My family isn't rich and I had some terrible experiences with loans and debt as a teenager so I didn't want to borrow any money. I still haven't.
The monthly hosting/support fee for the system is 600 EUR/month. I came to this number by taking the sum of money I needed to survive at my current level in Helsinki before taxes (around 6000 EUR/month) and dividing that by the number of customers I could support well on my own (10). I figured I could get to this number during the first year if I found roughly one new customer per month (keeping in mind that I had around 4 that I was already semi-sure about).
Things didn't quite pan out that way. Nearly all of the potential customers turned out to be dead ends and about 18 months in I still had only 3 customers which was nowhere near sustainable. I tried everything I could think of to gain more customers, but eventually accepted a job offer from an old customer for a Mac sysadmin position. The day job was a godsend and I've now been able to support my existing customers as well as pay my bills. That change means I no longer have to actively seek new customers.
I'm a shitty salesman. I have no illusions about that. Building and growing a business requires different skill sets and it's next to impossible to fill all those shoes alone. Having said that, my company has been in business for nearly 3 years, the system is running and hundreds of people are getting work done more effectively thanks to it. I'm also really proud of the fact that FPS also contributes quite a bit to charity (Doctors Without Borders, Reports Without Borders, The FreeBSD Foundation, Django Software Foundation).
Going open source
It was always the plan that Servo would be an open-source app. Initially, our main business would be running the service and this would basically be a side project. We would be developing the system for ourselves and testing it as we go. Then, when I left mcare, all I had was the code so I was too afraid of letting go of it.
The core GSX library has always been open source, although after nearly 3 years, I'm still the only commiter.
As the system grew and customers became more and more dependent on it, it became apparent that we needed a “disaster scenario” for the eventuality that something happened to me or my business. We discussed several options, but going completely open source solved all those problems.
When you really think about it, all mission-critical business apps should be open-source. It's really the only way to ensure that the application will always be available.
Publishing the source also puts extra quality demands on the code. I can't claim that it's made my code necessarily any better, but it definitely does keep you from doing some really stupid things (like hard-coding usernames or passwords).
It also feels really nice to be able to give back to the community. Servo couldn't exist without all the awesome free software out there.
Post scriptum
Servo has been such a big (and for nearly 2 years, the only) part of my life for so long that I could probably rant about it forever and ever, but I think those were the most important points I wanted to make. Feels good to get them off my chest. :-)