I built RideBits , a trip booking platform used by limo & taxi companies. The experience was much different that being a regular developer pushing out code for “the man”… Here is the advice I would give a future me on attempting the same thing…
Managing your mindset as you build
- Pay for things and use them. If you invent time to write any feature that a decent SaaS/PaaS can give you, you should punch yourself in the face. You can over-engineer when you have customers
- It is easier to sell to a similar type of customer, rather than chasing them all
- As much as you can, ask if what you are doing will influence the frequency of any of the following 2 events: “Start trial/Subscribe”, “Cancel account”. Don’t lie to yourself, you’re good at that
- When you get a customer, try to never refuse a refund request and be extremely professional and nice to customers. Don’t let angry blog posts be the first result for your company name.
- It is okay to fire that customer that is giving you stress. It is probably your fault, but bad relationships need ending.
- You don’t need every customer, you want the customers most likely to have and use your product
- Never give anyone that asks for a discount before using your software a discount. Not that it doesn’t work, but these will be coming from the most high maintenance customers
- Never promise to build a feature for a prospective customer. If the feature takes 2 weeks to build, you have no idea what may be most important to do in a week, don’t block for future time for a prospect.
- Listen to your customers. You are a developer so you won’t do this immediately anyway, just remember I told you so when you eventually realize you need to do this.
- Dare yourself to ship less of what you want to build, and plan to build the rest shortly after as people ask for it. You’ll be surprised at what they don’t ask for
- You will briefly feel rich after your first $XX subscription. However, it will hurt personally when the first few cancellations come in. Be ready.
- As a solo developer, there isn’t a failed state (you can always build another product), you can always adjust if you have not run out of enthusiasm
Technical stuff to get you done quicker
- Don’t worry about TDD, BDD, CI, Agile, XP, ASF, RED, RTY, APX, ABC or DEF. These are not activities for people like you without customers
- For app performance, avoid N+1, Large JS/CSS files, Avoid cheap hosting and use a CDN. Don’t pick a language for performance, they are all good enough. You can re-write it when you have customers
- If possible, pick a language strong on open source for ecosystem benefits and easier recruiting down the line. Still always best to use a language you know
- Use a JavaScript framework(i.e. AngularJS) to make your UX better, quicker. Forget the purists, Yes your code will bloat and become unwieldly, but the UX improvements will generate $$.
- Pay for Heroku (or something even simpler). The people you hire when you succeed can come and over-engineer hosting later
- Use good existing frameworks for complex things like authentication. Avoid frameworks and libraries for things you feel you can do competently in less than a day (i.e. activity streams, audit trails)
- Make sure there is a high amount of positive activity before using any open source repo. Don’t end up using a black box you can’t eventually get support on as you upgrade
