≡ Menu

I do a lot of work with legacy PHP applications that were never tested to begin with. Writing actual unit tests for them now would be impossible, and often the applications are so old that they won’t even work with modern versions of PHPUnit.

I suspect there are a lot of developers in this same situation. Still running PHP 5.1.6 because of an old CentOS or RedHat box? Want to write some tests for your procedural application that is comprised of many command line scripts? If so, I’ve released a new open source project called Throwback.

Throwback is a very lightweight, fast, and easy-to-use testing framework made specifically for testing legacy applications (they don’t even have to be PHP applications necessarily, but it’s probably best that they are – your tests have to be written in PHP). If you have a modern PHP application that uses Composer, the PSR standards, or an advanced framework like Zend or Symfony, then Throwback is almost certainly not for you – use PHPUnit instead. However, if you have a decade old application cobbled together with hundreds of thousands of untested lines of code, you will definitely want to investigate Throwback.

Throwback primarily works with backend PHP applications. Eventually it will support executing HTTP requests, but for now it’s primary purpose is testing command line applications written in PHP.

Checkout Throwback on GitHub to learn how to install it, and write and run tests.


Getting Dirty With Vagrant

No doubt by now you’ve heard of virtual machines. They’ve completely changed the way web applications are delivered and managed. But, did you know they can completely change the way you develop those web applications? Vagrant is a piece of software written in Ruby that does exactly that.

I started using Vagrant in May 2013. Work with Bright March was taking off, and I needed a way to manage all of the different environments I was developing in. My personal computer was getting cluttered as I was adding libraries system-wide for one single project (for example, one project would require the PHP OAuth library which would require me to install it system-wide for all projects).

On top of that, I was working with my business partner Neil and getting his development environment to match mine was troublesome – even using Homebrew. Some library would not be installed correctly, or some minor thing not in the right place, and we ended up wasting a lot of time getting the development environments set up.

Vagrant solved all of these issues for us. Vagrant is a command line interface that wraps several popular virtual machine software packages. The most popular, free, and easiest to use is Oracle’s VirtualBox. Vagrant works out of the box with it. The VirtualBox UI itself is just a graphical wrapper for several VirtualBox command line utilities. Vagrant takes that idea to it’s logical conclusion by providing a nice abstraction on top of the virtual machine software.

Vagrant also completely changes how you think about your codebase. Now, your development environment is part of your codebase. Simply drop in a configuration file that describes how to build a complete development environment (that ideally matches your production environment closely) and with a single command, vagrant up, everyone who has a copy of the codebase can have an identical development environment.

The power this grants your team should be obvious: regardless of what type of machine they use, all of them develop on an identical environment. Vagrant also supports features like NFS (Network File Share) so your files stay synced between the virtual machine Vagrant manages and your physical host machine. You can develop using whatever editor or IDE you feel most comfortable with and the files sync seamlessly with your virtual machine.

Vagrant supports the popular DevOps systems like Puppet, Chef, and Ansible for virtual machine provisioning. It also supports using a plain shell script, which is what I prefer (I’m not completely sold on the DevOps automation software yet, but I’m getting there). Check out the vagrant-bootstrap.sh script I go into detail about in my book Expert PHP Deployments on Github.

The beautiful thing about Vagrant is that you can implement it in your development cycle even if your software is years old. Simply add the Vagrantfile (the simple Vagrant DSL configuration file) and tell it how to bootstrap your virtual machine and you’re set. As your team grows, getting new developers up to speed will immediately pay for the time it takes to integrate Vagrant. It is amazing software, and well worth your time to investigate.

Important Links

Heroku Supports PHP, HipHop VM
Heroku, the infrastructure as a service company owned by Salesforce, recently announced they support PHP and Facebook’s HipHop Virtual Machine on their servers now. It’s great that Heroku is supporting PHP and HHVM, but I still find them a bit too costly for what they offer.

How I Design Software
Popular programmer @tef talks at length about how he designs software. The biggest takeaway from this is there is no obvious one way to write software; it’s a collaborative effort requiring multiple disciplines.

Firefox Updates User Interface
Firefox 29 was released on April 29th and came with a completely updated user interface. Jennifer Morrow is a Senior User Experience Designer at Mozilla and goes in depth on the changes you’ll see.

Disqus Discusses Realtime
Adam Hitchcock is a developer at the company that builds the popular commenting system Disqus. In this presentation, he talks about how they scaled their system to 165,000 messages per second using bare metal machines and a slew of open source software.

Programming Sucks
If you click on one link in this email, make it this one. This is a brilliant essay on software development and why it’s so difficult. It’s funny and insightful.


Worth the Click: April 2014

I apologize for not doing these for the past few months – life has been unpredictably busy. Here are a few links I’ve run across recently that have really helped me out.

  • brace.io – Extremely simple hosting for small static sites. I’m hosting the Employment Afterhours website there, and it works great. Your files are stored in Dropbox so editing them is simple and can be done on any device. Highly recommended.
  • Fuck Innovation, Everything Sucks – Another great post by Amy Hoy about how fixing the current things we use now can result in a lot of money and a better life for all involved. It’s one of the main reasons I’m building such a painfully boring product, it solves a huge pain point and makes money.
  • Employment Afterhours – I’m writing another book on how to start a software consultancy while maintaining a full-time job and not losing your sanity.
  • Idea to $5,000/mo – Baremetrics is a service for analyzing your Stripe account. I don’t use it personally, but it looks beautifully designed and very useful. This post discusses an important part to building a business: charge from day one. You wouldn’t build a consultancy without charging from day one, so why not a software product? I also love his point about just getting your product out there: very few people will remember version one. Do you remember version one of any product you use regularly (ok, maybe Gmail doesn’t count since it’s free)?
  • Running Tarsnap – Patrick McKenzie has an amazing essay on what he would do if he ran the backup service Tarsnap. Although long, it is filled with lots of great marketing information. Highly recommend you spend an hour and read this.



I loved the essay Programming Sucks by Peter Welch. It was funny, accurate, and insightful. Please read it – even if you’re not a programmer. It’s crazy what we’re doing with computers and how much they control. I don’t find the bridge analogy very compelling: humans have been building bridges for thousands of years. Literally every major bridge ever built would kill someone if it malfunctioned while they were using it. We’ve been writing software for around fifty years now, and most software won’t kill you if it malfunctions.

I once spent around three hours tearing my hair out because Symfony 2.3.10 absolutely refused to work with variable-line forms. It worked fine in 2.3.9, but upgrading to 2.3.10 broke it (I didn’t make that connection until much later). A developer added new code in 2.3.10 that broke variable-line forms, and it was reverted in 2.3.11. An absolute complete waste of an afternoon, and yet, we continue to work this way.

The way we write software is ridiculous and terrible, but it can only improve, and it’s the only thing I know how to do.


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.


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.