≡ Menu

Picking Your Purpose

I’m in the process of writing a new book and one of the introductory sections is named Picking Your Purpose. Picking your purpose means determining what it is exactly what you want your company to do. It is incredibly important because it will determine what clients you want to take on, how you brand your company, and how you go about growing your fledgling business.

The section is intentionally named Picking Your Purpose instead of Finding Your Purpose. Finding your purpose is a step you’ve already taken: you’ve discovered that you enjoy technology and want to build a profitable side business using it. Honing in on exactly what you want to do with technology is picking your purpose.

If you are a software specialist, like a Salesforce, SAP, or ATG consultant, picking your purpose is somewhat easier than if you’re in a larger more general field like software development (however, you may decide you want to focus on a single industry that uses specialized software).

When Neil and I first started our software consultancy Bright March, we had a general idea of what we wanted to do, but never finalized our actual purpose. It wasn’t until much later that we finally determined what we wanted to do: build custom analytics and metrics software for large datasets (the so-called BigData revolution). That’s a very focused purpose, but it’s what we really enjoy doing.

Instead, when we first started we took any work that was thrown our way. Neil is an incredible designer, so we took branding work, logo design, WordPress implementations, and general website development. While we were certainly able to do this work, we didn’t enjoy doing it and it distracted us from bringing on the clients we really wanted to work with (and absolutely no disrespect to the people who do that work – it’s incredibly vital, difficult, and necessary).

There’s a desire, and I certainly understand it, to take on all work you come by when first starting out as a consultant. You might have a certain talent, and someone is willing to pay for it, so there’s a natural desire to take on the work. But, and this is crucial when you’re first starting, you really need to analyze the work presented and determine if it fits your purpose. If not, it’s better for you, and your potential client, to politely turn it down and help them find someone who is better suited for it.

Picking your purpose might be the most difficult part of starting your company; filing the paperwork and buying a domain is simple. But picking your purpose up front will mean you’re focused on the direction you want to take your company in the future.


Employment Afterhours

A lot of developers I know usually want to start their own company. They see how much money the company they work for makes, and think they can do something similar and reap the same rewards. It’s usually not that simple. Building a successful software company is a multi-faceted operation where the software is often a small component of it.

I recently stopped working full-time on Bright March and returned as a full-time programmer at another company. A lot of people might think that Bright March is a failure (and admittedly, I feel this from time to time). Rather, the opposite is true. I have a small set of trusted clients that I enjoy working with, and my business partner and I can get the necessary work done while still both maintaining full-time jobs. This allows both of us to get a great salary while socking away the money we earn with Bright March so we both have a great retirement ahead of us. Additionally, I’m returning to the company I worked for prior to running Bright March full-time, which made the job search incredibly simple.

I’ll certainly miss the freedom that comes with running my own company. Being able to take off as much time as needed when my second son was born, or working odd hours to make up for his sleep schedule, or taking a random Friday off to go on a date with my wife are all great (and good progressive companies would find their employees can still be productive even with freedoms like those). I won’t miss the constant struggle of finding new work, ensuring clients pay on time, paying myself as little as possible during dry months, or any of the many other stressors that come with running a company.

Admittedly, I would have loved for Bright March to have been a huge smashing success that generates millions of dollars in revenue a year, but that’s very unlikely to happen – at least in this stage of the business. Instead, I’ve learned that working for someone else isn’t the end of my career as an entrepreneur, and there are plenty of people who have great financial success later in life as well. This change has made me realize that work isn’t everything in life, and there’s no reason I can’t have a fulfilling life as both a full-time employee and entrepreneur. There are many great developers that I follow online that appear to be fine working for someone else.

Back to my original point: a lot of developers really want to start their own company. But quitting your job and announcing to the world “here’s my company buy my stuff!” is usually a horrible way to go about doing it. We started Bright March while both of us were employed full-time, managed to make nearly $100,000, and bring on-board several long term clients that are still with us today.

We were able to do this with very little financial risk to ourselves and our families as we both had full-time jobs, and earned a decent amount of money that allowed me to jump off and do Bright March full-time in March 2013.

Realizing other developers are in this position as well gave me another idea for a book: how to start your own software consultancy while still being employed full-time regardless of the end result (consult full-time or continue both jobs). It would cover the following topics:

  • How to set up your company
  • How to grow your personal social network
  • How to get and maintain clients
    • Organizing in-person meetings
    • Being honest about your situation
  • Negotiating with clients
    • How to never lose money on work
    • Understanding your clients risk
    • Should you ever do free work
    • What’s the minimum you should charge
  • How to work two jobs and not lose your sanity
  • Setting up the perfect retainer
  • What type of clients to pursue
  • How to improve your own value to your clients
    • One small afternoon hack netted a $48,000/yr retainer

The book would offer practical advice over what I call “pure advice”. Pure advice would be along the lines of “never do anything work related while at your job!” That would be great, but it’s not practical. If the server that runs your clients application goes down, you’re going to havae to do something. Practical advice would cover how to handle a situation like that – and it will happen – so that you don’t neglect both your work and client responsibilities.

This book would be named Employment Afterhours. It would teach you the ins and outs of starting, running, and maintaining a full-time job and a side business.

Imagine if you picked up one extra client this year at $4,000 a month. At $100/hr (the minimum you should be charging, and this will be covered in the book), that’s only an extra 40 hours a month, or 10 hours a day. With that single client, you can save (or spend) an extra $48,000 a year. And that’s with a single client. Just one. Employment Afterhours will teach you all of that – and a lot more.

If you’re interested in Employment Afterhours, please visit the website and sign up to hear more about the book. I’ll be publishing snippets through that email list, and will announce when it is finished. If you have a specific question, comment, or recommendation, please email me.


A History of Failure: Learning From My Failed Products

Right now you’re reading the blog of someone who has had no major success building a profitable SaaS solution. Writing customized software for clients as a consultant? I have that down (though always looking to grow). But building a profitable SaaS product: not yet. So why should you take my advice about building one? I have a really great track record of failures that I hope can help you when you’re building your next product.

Building a failure of a product is no fun, but each one serves as a great learning experience. Each one of my failures have influenced the next product I built. I’m building my three new products differently now that I have several failures under my belt.

Lastly, I don’t want to promote the idea that having a failed product is necessary to be a competent entrepreneur. Unquestionably I’m envious of people who have successful products on their first try. However, I’m always suspicious of those success stories; sometimes a success story is better sold when the list of previous failures is left to lie silent.


The first product I sold online was named Kwolla. Kwolla was the result of a failed startup I was hired to build. Kwolla was originally named Prospect Vista and was a social network for businesses. You could think of it as a merge between YouTube and LinkedIn because a public profile that advertised your business was the value proposition. There are many reasons why Prospect Vista failed, but we decided that the software behind it was still valid, so we packaged it up as a social-network-in-a-box tool. For $79 you could buy a copy of the software, install it on your server, and instantly have your own social network.

Selling Kwolla actually went very well. In total I sold $2400 worth of software and Kwolla consulting combined.

Kwolla failed because I essentially shut it down. I made two big mistakes. First, I had this notion that I no longer wanted to write PHP anymore, and thus was going to rewrite Kwolla in Scala. Next, I actually started rewriting Kwolla (in PHP albeit)! This was insane. In my hands I had a product that was making money and I shut it down because I didn’t like the codebase behind it. The code was sloppy in places and it bothered me. So I completely killed it.

It was a horrible decision. I wish I would have kept on building the Kwolla site and product. Over time I could have refactored the code and made it better. But, my the engineer side of my brain kicked in and I couldn’t deal with the bad code.

Key Takeaway: Don’t rewrite major software applications from scratch, and keep on with a good thing.

Accthub Version 1

After I shut down Kwolla, I went to work for an e-commerce company for a while. I concentrated on building my consulting business on the side in that time, and didn’t really work on any projects for myself. While at the company, I had an idea to build a centralized user management API so that our many different e-commerce sites could communicate with this central user management API. I was itching to build a product again, so building this central user API seemed natural.

I wrote out a spec and eventually built the API: Accthub. A hub for all of your accounts. Neil, my co-founder at Bright March, designed a beautiful landing page and we built a great marketing site around Accthub.

We launched to absolutely zero users. We attempted to market it as a Parse for user accounts (even though Parse had user accounts). In total, 76 people signed up for the service and not a single person paid for it.

Ironically, even though this idea failed for us, two other companies are building it: Stormpath and UserApp. It’s clearly something people wanted, I just hope they have more success than we did building their applications.

Key Takeaway: Do market research before you spend a tremendous amount of time and effort building a product. Launching it to no one doesn’t help at all. Even worse, I originally wrote Accthub in Java and then completely scratched it and rewrote it in PHP because I knew it better and was more comfortable with it.

Accthub Version 2

It’s funny how the key takeaway in the first iteration of Accthub didn’t hit us until after we attempted to re-build Accthub again. The second version of Accthub aimed to be like Mozilla Persona, except not free, not from a major highly respected non-profit company. Essentially, you, the Internet user would register an account on Accthub and then use it to sign up for other sites that integrated with Accthub. Then, you could give explicit permissions as to what every site could do with your data that you let them use.

This idea sounds really cool, but there are a lot of problems with it. Who is going to pay for it? Internet users won’t, they’ll clearly give their private information away for free without any thought. Companies won’t pay for it, they can just use Facebook, Twitter, or LinkedIn authentication.

We applied to Y-Combinator with this idea and didn’t even get an interview.

Key Takeaway: Really validate your idea before you build it. With Accthub Version 1 we got some traction. Fortunately with this version, getting rejected from Y-Combinator was enough for us to scrap it before we built it in earnest.


MajorApi was the first product we built that showed a lot of promise. With the strain of failures behind us, we knew we wanted to approach MajorApi differently.

MajorApi was born from the idea that integrating with QuickBooks is really, really difficult. Way more difficult than integrating with any database (essentially what QuickBooks is) should be. We were working on integrating with QuickBooks for a client and spent a huge amount of time just figuring out how to connect to QuickBooks and send in and extract data. Judging by the the thousands of StackOverflow and random forum posts out there, we surmised a lot of other developers were having this issue as well.

So we came up with an idea: a REST API for QuickBooks. We finally cracked the “integrating with QuickBooks” code, and felt that if there was a service that charged a monthly fee to provide a nice API on top of the horror that is integrating with QuickBooks that developers would come rushing in to use it.

To validate this idea, we set up a simple landing page. It explained the problem, our idea, and our proposed solution. I submitted a link to it to Hacker News on a Saturday night in early December 2012. That night, the post blew up. We had several hundred people sign up for the mailing list saying they were interested in what we were building.

Even more encouraging, Intuit themselves caught wind of the landing page and flew me out to Mountain View to spend a day with them. They offered me a very nice job in exchange for not building MajorApi. Stripe was also interested in integrating MajorApi with their service. So, when Intuit offers you a job to not build something, and Stripe wants to integrate your product with theirs, and you have hundreds of people interested in using it, it’s definitely time to build your product.

I declined the job at Intuit and built MajorApi. And three months later in March of 2013, we launched it. And people started using it – kind of. And then really not at all when you really looked at the analytics. Mailing list people signed up, saw they had to download a piece of software, and it only worked for QuickBooks Desktop and that was it: they were gone.

We also applied to Y-Combinator with this idea which we felt surely would get us an interview only to wind up completely rejected again.

MajorApi limped on for the last year. We finally shut it down in January 2014 and are in the process of open sourcing it.

Key Takeaway: We built a product that people were interested in, but we built it in a silo. We didn’t reach out to any members on the mailing list while we were building it to find out what they really wanted or were willing to pay for. Instead, we kept our heads down and built a product we thought people would have wanted. I would have much preferred to launch to 20 developers immediately ready to start paying $50 a month for this service than 200 people who created a free account.

Final Thoughts

Building a successful product is hard. Very hard. I’m not ashamed at all about my failures. Even the most successful products out there were most likely built by people with a long history of small failures that they learned and grew from.

It’s always best to put another tally mark in the Successful column, but don’t be ashamed of the ones in the Failed column either.


Worth the Click: January 2014

2014 is going to be the year my business becomes huge. To do that, I have to start thinking a lot more like a marketer than a programmer. I’ll always love programming and software development, and I’ll always ensure it’s part of my profession, but to really accomplish my goals I need to grow. January’s “Worth the Click” is focused more on marketing than programming. Here are some posts I read recently that really helped me out.

  • Idea to Customers in Three Days – Few posts got me as excited this month as Brennan’s “How I Went From An Idea To Paying Customers In 3 Days” did. This excellent article details how he went from a WordPress plugin idea to paying customers (at $197 a pop) in three days time. It contains tons of actionable advice, and really got me excited for building my products. I’ll be duplicating his actions in this post for a product idea I have and documenting it all the way.
  • How Do You Create a Product People Want – Building a product people want is hard – really hard. But you can save yourself a lot of headache and trouble if you follow Amy’s advice in this article. I know I’ve done steps 1 through 6 with several of my own products many times.
  • Do You Cold Call – This link is not an article but rather a Hacker News discussion on cold calling. It done properly, it can be quite effective. The discussion is great because you get feedback from people who do a lot of cold calling and people who get cold called a lot. Tons of great advice in this discussion.
  • Guide to Surviving Self Employment Software Development – This article has some great advice on how to get through self employment. Marc’s advice on overbooking is valuable: it’s a nice position to be in, but it can actually sink your business quickly. Each tip in this article has a nice Lesson Learned summary at the end if you’re in a rush.
  • Cold Emailing – Does cold calling intimidate you too much? Try a cold email instead to get your feet wet. This article from Noah Kagan shows exactly how a cold email should read.

We Open Sourced Our Failed Startup

MajorApi was our first legitimate attempt at building an actual startup. We thought we did everything right (for some definition of the right way to build a startup), but it still didn’t take off.

We put a lot of work into MajorApi and we’re very proud of it. Rather than just let it linger on an external hard drive in a Time Machine backup, we decided to open source it.

The code is MIT licensed and is comprised of two repositories: the main website and QuickBooks REST API, and the background data processing workers. Personally, I’m really proud of the code. It’s well tested and solves a relatively complex problem. It also demonstrates a great way to build a REST API in Symfony using one of our bundles. The main website was also beautifully designed.

While we’re not actively working on the project now, we are doing custom QuickBooks integrations. If you need to integrate with QuickBooks, get in touch with Bright March.


Sales Tips I Learned as a Personal Trainer

Like a lot of programmers, I used to view marketing and sales as something that was scummy and below me. It amounted to essentially tricking people into giving you their money and they didn’t get much in return. It wasn’t until I became a salesman that my view on sales and marketing completely changed.

When I was in college in 2003 I became very interested in fitness and bodybuilding. To say it became my life would be an understatement as I spent many more hours at the gym than I did in a textbook or classroom. So, it was natural that I eventually got a job at a gym: why pay $40 a month when I could work there and use the equipment for free?

I got hired at the now-bankrupt Bally Total Fitness to manage the front desk. I was paid $8 an hour to scan cards, take payments, and direct people to salespeople or personal trainers. I absolutely loved that job. It was simple, and during a lot of slow times, I could work on classwork or personal projects. Eventually the gym changed directions and I was given a choice: either lose my job or become a personal trainer. I obviously wanted to stay employed, so I opted to become a personal trainer. This wasn’t an easy choice, since being a personal trainer essentially means that you’re a salesperson that also trains people. Sales ended up being about 70% of my job, with training being 30%. In the end, however, I enjoyed the sales much more than I did the training.

Within one month of being a personal trainer, I was the #1 trainer in the Dallas/Ft. Worth market selling around $12,000 a month in personal training.

Don’t Sell Anything

The biggest lesson I learned was to not try to sell anything at all. People hate being sold things, but people love buying things. Bally taught trainers and salespeople to be as high pressure as possible. Intimidate people into buying a membership, or offer ridiculous incentives that they can’t live up to. Coincidentally, Bally is now bankrupt, so those tactics don’t work long term. Instead, I made sure hiring a trainer was a choice the person wanted before they committed to a $2700 personal training package.

Instead of viewing the sales process as a process, I saw it as an interview. I was interviewing a potential client to ensure we fit well together and they were committed to changing themselves. This meant I had to give away a lot of free time and expertise, but ultimately this tactic succeeded.

Finally, I didn’t want to pressure anyone into an expensive package because I was going to be the person training them. Did I really want to train someone who started off disgruntled at me because they felt they got ripped off?

Show Your Investment

Sales comes down to many things, and one of the largest is trust. Can the person trust you enough with their money that they are going to get a return in some way on it? You gain their trust by showing your investment in what they are buying. For a personal trainer, this means being in good shape. Listening to their goals and tailoring a fitness plan for them. This shows you’re invested in them, and in return they’ll invest in you.

I showed my investment to my clients by keeping meticulous notes about each of their workouts. When I was interviewing a client, I would produce a little notebook that was filled with exercises and goals. I would explain that this was the exact notebook I used to track my goals and progress (it was) they would get their own notebook that I would use to track their activity. That way they could see their progress as well as hold me accountable for their goals.

Don’t Rely on Typical Sales Channels

The typical personal trainer sales channel was this: a person just registered for the gym, and now they get one free session. A trainer is chosen to give them the free session, and then the trainer tries to upsell them on more training. You can imagine how unsuccessful this was. Talk about having the person feel as if they are being ripped off. First they sit through a high pressure membership sales pitch, hesitantly agree to it, and then have to sit through a high pressure training package. I never got the conversion rate on that practice, but I couldn’t imagine it was very high.

Instead, I found much better ways to bring in clients. Every Bally gym had several dumb computer terminals that connected to a central server that did all of the processing, reporting, and data storage. One of the features of this system was that you could run reports on members. Before they locked it down, I would create an ad-hoc report that would show me all people in the area that had expired personal training sessions. I would call these people up, say if they came in I would give them half of their sessions for free, and if they liked my training style, would they consider hiring me as a trainer? This worked amazingly well. You can imagine how much easier it is to sell someone training when they have already purchased it before. My conversion rate was a cool 50% (I called 10 people, 5 became paying clients).

A typical sales channel for your SaaS product is you create an ad through AdWords, wait for a few visitors, maybe one fills out a registration form, and you might make a sale. While this is perfectly valid and scales well, it’s certainly no way to get your product growing.

A much better sales channel is to build an audience. One person doing this very well, and the person who taught me this strategy, is Brennan Dunn. I became aware of his products several years ago and have been following him ever since. I registered for his newsletter, listened to his thoughts, and got tremendous value for free, so when he started The Freelancer’s Guild, the $50/month fee was trivial to pay.

It’s so much easier to get someone to buy something from you when they already trust you because you’ve given them tremendous value for free. As a personal trainer, this meant I might give someone two or three free sessions to ensure they really are dedicated to training. But if giving away $80-$120 of my time meant I sold a $2700 training package, well, the math is trivial.


The Dynamics of the MVP Have Changed

Every developer I know has an idea that is going to make them very wealthy. Most don’t act on the idea, and most ideas don’t make them any money, but they all have them. The key, of course, is action on that idea.

The initial action on that idea is called your MVP, or Minimum Viable Product. It is the minimum product you can build that you feel can gain some traction, or viability. Unfortunately, determining what that product looks like is very difficult and ever changing. It also requires you to have knowledge about your expected customer, and to fit your product for that customer.

In the early days of web application development, an MVP was a fairly polished product. It contained many features, usually took months to build, and looked solid (under the hood it probably wasn’t). Today, that delta from idea to the first code commit to the first production deployment can take as little as a few hours. This is still a reality I have trouble grasping as I struggle with overcoming perfection. Literally every single product I have released didn’t feel polished enough and I always have spent way too long worrying about features that no one ever uses or needs.

An exercise I do to get around this mental block is to ask myself these two questions:

  1. Will this MVP validate my idea quickly and accurately?
  2. Will this MVP allow me to on-board my initial customers?

If you can’t answer “yes” for both of those, then it’s probably best to move on to your next idea.

After you have determined that your idea is worth pursuing, it’s probably best to determine exactly what your MVP needs to do. In other words, how much pain am I willing to experience before automating this process? By answering this question, you will discover what pieces of your MVP can be automated, and what can be manual.

For example, Groupon started as a simple spreadsheet and WordPress blog and then grew from there as manually tracking coupons became too painful. With Forwarder, I knew that it needed some semblance of automation because I could not manually route calls myself. With MajorIntel, we’re working with customers one-on-one to build beautiful QuickBooks reports for them every week.

Coding and hacking and building things is a lot of fun. What is not a lot of fun is building something that no one uses. It’s a good use of your time to ask yourself a few questions before you run off and start building your MVP.


Symfony Hosting

I host this blog on a service called WP Engine. It is excellent and I highly recommend it. One of the biggest hangups I had with WordPress is that I didn’t want to host it myself. Even a cheap $5 Digital Ocean VM was more of a headache than I wanted. WP Engine (and others) came along and solved that problem beautifully.

More and more Open Source projects are moving in that direction: a company forms around the project itself that offers hosting and white glove service. It’s a great business model as it helps to fund the core software while providing a way for people to make a living.

Most of the software we write for our clients is done in PHP using a framework named Symfony. Symfony is quite complex, but very powerful. With the exception of a company named ServerGrove, I have not seen any dedicated Symfony hosting providers.

I’m interested in building a hosting service specifically for Symfony applications, and even more specifically, large scale Symfony applications. We would provide a lot of white glove services including:

  • Help with no-downtime deployments.
  • Symfony configuration management.
  • Scalability options and help.
  • Database optimization.
  • Symfony and server security.

All applications would be hosted on actual hardware that we would manage and be responsible for.

Is there a need for a service like this? If you write and deploy Symfony applications, how do you do it now? I would love your feedback. Either leave it in a comment or email me.


Worth the Click: December 2013

December came and went very quickly. A lot of that had to do with the holiday season; I just didn’t feel as productive as I could have been. Regardless, 2013 was an amazing year: the year I finally struck out on my own. I hope 2014 will be even more amazing. Here are some links that are worth the click.

  • Cold Calling – This guest post on the Smart Bear blog details how to start cold calling potential customers. Cold calling is very difficult, and people are right to be weary of it. However, Robert gives some great scripts on ways to talk to people. It’s all about what you can offer them.
  • REST APIs With MartiniMartini is a popular web framework for Go. This tutorial walks you throw how to build an API with it.
  • Five Tips to Running SaaS – Thomas Fuchs of Scriptaculous and Zepto fame wrote about five things he has learned in the five years of running a SaaS company. Number five is particularly important to me.
  • Failures From Entrepreneurs – This post from Buffer resonated with me. While I haven’t wasted $1,000,000 on a business or taken outside funding, I have spent a lot of money on failed ideas, said “yes” way too often, and built things no one wanted. Chances are, you’ve experience many of these as well.
  • Know Your HTTP – Helpful printable PDF’s on HTTP.
  • Startup Lessons Learned From a Failed Startup – Great article detailing how hard it can be to build a product online, and how easy it is for them to fail. I’ve done this several times, and will talk about it in an upcoming post.

The Problem With Framework Benchmarks

I’m a huge fan of the recent benchmarks Tech Empower have been doing against a wide array of web frameworks. It really is shocking how fast some of them are.

However, benchmarks like these fail to take a very important piece of software development into the equation: the holistic development experience.

Measuring speed is relatively easy. Measuring how easy it is to develop using a specific framework, the tools and libraries available, the community, the professional learning tools, ease of deployment, ease of updates, and how frequently the core framework is updated is much more difficult to measure.

For example, in Round 8 of the comparison, Go comes out on top for JSON serialization. This naturally makes sense, as Go is a new fast compiled language meant for speed. Symfony comes in dead last. But any programmer would tell you to use Symfony just to output 28 bytes of JSON is silly. Raw PHP is quite fast, and beats out a lot of other frameworks and languages.

Also, because Go is newer, it doesn’t have the ecosystem that Symfony and PHP or Rails and Ruby or Django and Python have. These languages and frameworks might not execute as quickly, but the libraries, development and debugging tools, and communities available will help you develop and maintain software much faster and easier.

As with most software development, there are tradeoffs. Can your web application suffer an additional 10ms of processing time because you’re using a slower framework if your developers can be a lot more productive? That’s your call to make.

Now, I’m off to go investigate Vert.x and Netty.