Four years ago, I tried to start a development agency called Row & Table. While we had a few successful projects, we also had some big failures and I ended up in debt and discouraged by the whole experience. (I basically shut the company down, keeping only the domain and the LLC.)
About the time I started to close down Row and Table, I got a job offer from my friend Dan Irmler. Dan has worked in software for years and had recently sold a successful SAAS to a larger software company and had a few projects he wanted me working on.
Over about a year, we realized we worked very well together. We started hiring more developers and taking on more projects and we’ve recently decided to relaunch Row & Table as a partnership, but with a different focus this time (version one SAAS projects.)
In light of relaunching Row & Table, I want to reflect on the five main mistakes I made on the first go around and what I’ve learned in the intervening period:
1. I couldn’t do the job myself.
When I first launched Row & Table, I thought I knew a lot about web development. In actuality, I just wasn’t ready yet. I was close and I certainly knew more than most, but there were too many things I couldn’t do.
In the intervening time, I focused on becoming a better developer and learning how to make software myself. I made a few SAAS projects from start to finish with no outside help, I really learned tools like Laravel, Vue and Tailwind, I just learned a ton.
I’m still not a great developer by any means, but I could jump in and do the job of anyone I hire. Maybe not as fast and maybe not as well, but I could do it. And that makes me much better at hiring and managing people than I was before because now I know what questions to ask and how long things should take.
2. I didn’t charge enough
I always felt weird charging for my services and would tend to undercharge or charge with such thin margins that I was almost certain to lose money. After two years of this, I wasn’t just not making money, I was in serious debt.
One quote changed that for me. Someone said
You have to charge enough that you can keep your promises.
That quote, probably more than anything helped me understand that undercharging my clients was actually hurting them because there were things that they wanted more than money (or they wouldn’t be paying us in the first place.). They wanted:
- the job to be done right
- me to communicate well
- us to be excited about the project
- us to hire the best people.
In order for those things to happen, I had to completely rethink how we were charging our customers. We are still on the low end for this industry, but nowhere near the ridiculously low prices we were charging two years ago.
3. I didn’t hire the right people
When I first started, I hired some good people, they just weren’t the kind of people I could rely on for client work. I had to learn the hard way that the ability to do something is only one part of what you look for when you hire designers and developers. I had to learn that their communication and self-management skills were just as important.
4. I didn’t spend enough time communicating
When a client hires you to do a big project, they are taking on a big risk. Not only are they putting up a lot of money, they are investing an incredible amount of time and intellectual capitol. While I was never terrible at this, I didn’t realize just how important client communication is during a big project.
5. I didn’t have solid project management practices
When I first started, I didn’t realize how much I needed a project management workflow. We tried every project management tool out their (I honestly can’t even remember all the things we tried.) Several different communication tools, and mostly just resorted to managing projects in Github. It was a mess.
One of the first things Dan did when we started working together was send me to get SCRUM certified. Both Dan and I are project management geeks and we are constantly reading and honing our project management practices. We use Basecamp to manage our projects, plan out work in two to three week sprints, and communicate through the sprints both with developers and clients the entire time.