≡ 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.


Selecting Your First Client

Now that you have your purpose for starting a consultancy, you need to select what kinds of clients fit that purpose. Finding the answers to these questions is important, which is why you should ask them, and spend some time answering them, before you even attempt to find your first client.

I understand – you’re ready to take on that first client. You have the skills, and that extra money would be great! I get it, but answering these questions will ensure you select a good first client, your first project is successful, and most importantly, it doesn’t leave you resentful for further client service work.

Just like there is no right or wrong purpose, there’s no right or wrong first client – just clients that are a good fit and not a good fit for your services and personality. Selecting a client that isn’t a good fit can sink your burgeoning company: you’ll end up losing money, time, and the desire to continue working with that client.

In Picking Your Purpose, I discussed some logo work and branding we did when we first started Bright March. The work was easy enough: build some small, static web sites, design a few logos, and do a PowerPoint presentation. We completed the first stages of the project quickly, and the clients were happy with our work. So happy that they immediately hired us on for some additional work: design logo’s for the churches the owners of the company belonged to, build a website to petition the state of Texas to allow them to build their private airport (they were very wealthy oilmen, but owned several small companies), and a few other things that didn’t sit well with us.

We did the work, but they could never agree on the church logos, and gave us absolutely no direction on how to build the petition website. Moreover, they refused to pay our final invoice (a loss of $1500), and we had no final work we could even use in our portfolio.

Of course, we could have sued them for the work we weren’t paid for (we had contracts in place, of course) but it wasn’t worth our time or effort to file a lawsuit in a county hours away from where we live – so we cut our losses and used it as a learning experience.

Fortunately, we could easily absorb that loss because we were both employed full-time. If we were running Bright March full-time, that $1500 might have been the difference between shutting down and staying open (cash flow is that important when running a small private business).

In hindsight, we obviously should have never selected that client. Like I said before, these clients weren’t wrong, they just didn’t fit us. There are people who are happy creating church logos and making conservative website petitions, but we’re not.

I recommend small-medium size businesses (SMBs) for your first client. Startups are too risky (especially if you don’t know if they’re well funded or not). If a startup goes bust, you’re definitely not going to get any money owed to you. Plus, a lot of startups are risk adverse and cheap which is not fun to deal with.

Giant corporations and government entities are probably not your ideal first client either. If you have the ability to land one as your first client, that’s great – it usually requires some incredible connections. But they’re going to control you each and every step of the way, including when you get paid, what your rates are, who you can work with, and more. Don’t like their net-90 payment terms? Tough, there are hundreds of other consultancies who are happy to take them. Sure, you’re likely to be paid without much discussion (Intuit once almost paid me $10,000 because they got consultants mixed up), but doing the work now and getting paid three months later is tough.

SMBs are ideal because they’re generally doing something profitable, have probably worked with small consultancies in the past, won’t require an insane amount of lawyering or bureaucracy on your part, and you can make a deep meaningful impact on their business.

Even better are SMBs that do really boring work. Why? Boring work is profitable. No one does boring work because they love doing it, they do it because it makes a lot of money! One of our favorite customers owns a very large home services (electricians, plumbers, HVAC techs, etc) company in Dallas. We built a really boring piece of software for them – it’s a basic CRUD app that records information about the work the technicians do.

It’s nothing exciting but it saves them a tremendous amount of time and money every month. They’re great to work with: they know their industry well, they’re very profitable, they’re big enough that they’re not going out of business, but small enough that I work directly with the owners. They’re an ideal client for Bright March.

I recommend you select your first client when you’re employed full-time. It gives you a tremendous amount of freedom in who you select. At this stage, you should be selecting a client because they’ll offer you the ability to make some side money and the work is challenging and rewarding.

The final part to selecting your first client is learning to say “no”. I understand that “no” means turning down money; I get that pain. Finding that first client might have even taken a lot of effort - but if the client isn’t a right fit for you, saying “no” is one of the best things you can do for your business.


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.


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.