When I first started consulting, I had everything tied to my name. My company name was Treb Studios, my email was firstname.lastname@example.org, and my whole business was tied to me.
This was fine for a while…until I started growing. I hired contractors with the intention of replacing myself on my existing projects. This proved to be very challenging.
Clients didn’t want other developers, they wanted Brandon, because that’s what they were promised.
It wasn’t until I started using “we” language instead of “I” language that clients fully accepted my other team members. Changing the language also had a profound effect on how I perceived the company. I began looking at everything as a real company rather than just me hacking on the side.
So, if you are building a company (even if it’s just you), start using the term “we” instead of “I” from day one. It will make the transition much easier when you start growing, and it will make you feel like you are actually building something beyond yourself.
Tonight, I'm going to a party for local entrepreneurs.
I was getting ready for the party and thinking about the signals I am sending with every detail I put into my appearance. How do I want to be perceived? Should I go combover or faux-hawk, slacks or jeans, watch or Fitbit, leather or suit jacket? All of these decisions don't necessarily paint the picture of Brandon, so much as they paint the picture of who Brandon wants you to believe he is.
While it may seem vain to contemplate on what signals I'm sending, people do the same thing ALL THE TIME without even being conscious of it. We do this not only in real life, but especially on Social Media.
Seth Godin will often write on sending signals.
He has a great quote from the post:
Empathy helps us understand what will be received, and intent dramatically improves our effectiveness.
Understanding that you are always sending signals AND having empathy will not only get you further in business (since you can understand the signals you need to send on an individual basis), it will also get you further as a human being.
This also has me wondering. What signals do I send to myself?
I have really been enjoying listening to Darknet Diaries lately. It’s a Podcast about hacks and software security vulnerabilities.
The show really makes me realize how crappy and insecure most software is. Most importantly, it has gotten me much more security-minded in the software that I build.
If you aren’t already listening to it, I’d suggest you check it out. You will soon put on your tin foil hat like me and start to believe everybody is trying to hack you.
My wife and I are hard core “type-a” people. I mean, so planned that we send each other calendar invites for date night (don’t judge what we consider romantic ;)).
I didn’t used to be like this. When I was younger and in college, I was a total scatter brain, a C student by choice.
This all changed the day I was laid off and had to start my own company. Owning a business requires me to pay attention to every detail, every invoice, dev rate, hours budget,etc… Its exhausting and college Brandon would have been out years ago.
Fortunately (and I can already feel this sounding like a sales pitch), I use Bullet Journal. It’s basically a system using only a notebook and pen to organize your life. Think 90’s style leather day planner.
While I don’t use every “module” that it offers, I use the system to manage todos, notes, long and short term goals, and lists (this blog post title just came from one such list).
So, if you are like I was, I highly recommend bullet journaling. It will change your life for the better (worse?).
Many of you might not know this, but my family and I live in a converted schoolbus.
Today, I had quite a few “bus chores” and I figured that I would share them here because together, they do seem a bit odd.
- Change composting toilet
- Fill up propane tanks
- Add heat tape to fresh water lines
- Replace RV vent in roof because it started leaking
Sometimes I wonder if I have more chores on the bus than in a traditional home.
Whatever, off to chop wood for my tiny wood stove…
The other day, I was having a conversation over Slack with my development team. They were working on a client project (and doing a killer job), and there was a particular UX pattern that seemed very unintuitive to me. This app was designed by the client, so there was little the dev team could do beyond making suggestions, so they went ahead and implemented it per the spec.
After fiddling around with it for a few minutes, I literally couldn't understand how to complete the particular task and had to ask the team lead for some help. He assured me that it made sense and offered to walk me through the architecture and data models to help me better understand the flow.
Sometimes, as developers, we understand these super complex systems solely because we architected them. They seem intuitive to us because we know the underlying data structures and algorithms involved. When we are speaking to other developers about those systems, they usually get it too, because they understand things at a software level.
This doesn't always translate well when it comes to UX design for the end-user. I believe developers have a bias when looking over the product in which they are creating. It makes sense to us, so it must to everyone else. I opted to not learn about the underlying code, so that I could better QA the product by removing some of this bias.
Next time you are testing your software, have as many people not involved in the project test it as possible. Given them very little context. Watch them use your product. Find out what is intuitive to them and what isn't. You will be pleasantly surprised and your software will be better for it.
How to Retire Forever on a Fixed Chunk of Money - Mr. Money Mustache
Another solid post from mmm. His blog was one of the first I read that set us on the path of financial freedom and minimalism.
If you don’t already know about him, I’d suggest starting at the beginning and reading through all of his posts.
I promise it will be worth it.
My little brother was recently in town for the holidays. He’s about to graduate from college with a CS degree, so naturally we talked about searching for a job.
I figured I would share the advice I gave to him here in hopes that it might help others.
Don’t be discouraged when you get turned down. Having hired many employees over the years, I have learned that there are so many reasons to not hire a candidate. Much of the time they don’t even have to do with qualifications. In the past, we would just interview with no intention of hiring to test the waters.
Work with recruiters there is little downside in working with recruiters as a job seeker. Give them tight parameters about what you are looking for (position, location, etc…) and tell them not to bother you unless there is a match. Often, recruiters will have better “ins” with hiring managers, so your resume won’t get filtered as often by some algorithm.
Network I almost wrote that in all caps. Attend local meetups, take people out to coffee, and get connected in the local tech scene. Don’t give me that “I don’t live close to tech” nonsense . I live in a suburb of ABQ (not a big tech town) and still managed to build a killer network of tech locals.
Always be searching for a job (especially if you already have one). Part of your job, is to find a job/a better job (or at least leverage to get paid more in your current) (longer post on this later).
Shoot for the stars, but be ok landing on the moon This is more for new grads. Landing a job will give you that confidence boost you need to begin your life outside college. So, don’t stress about landing the dream job at Google on day one (by all means apply though). Just take a job and then see the previous bullet point.
Happy job hunting!
As developers, we spend so much time perfecting our craft. We are always on the hunt for hacks, tips, and tweaks.
We always set out to write the most clever and reusable code possible. This is all great…until it’s time to ship.
I have seen it time after time. Developers over-optimizing their code, writing protocol after protocol. All the while, they slip further and further behind schedule.
When the client asks the dev about the delay on feature X, the dev proceeds to explain the super cool reusable, component-driven,state managed, highly available, future proof, buzzword, buzzword system they are creating. The client literally doesn’t care about all that. They just wants to see feature X working.
I love clever code as much as the next developer, but sometimes you’ve got to table your inner CS geek and just ship something that works. Then, refactor later.
In our house, we often joke that “the diet starts Monday”. Usually, this is in response to some conclusion that we are not currently on the healthiest path.
Procrastination is in our DNA. We put everything off until the absolute last minute. For me, it’s usually side projects. Projects that I know will make some revenue to supplement some of my consulting income. It’s my goal to eventually move on from consulting, however that has been on my “resolution list” for years, with little progress.
I’m committed to finishing one such project before the years up. I should get hacking on it…on Monday.
It’s often much easier to have a sense of gratitude when things are going well. As humans, we are prone to focusing on the one bad thing that’s going wrong rather than the multitude of good things going right. This traces way back to a time where we needed this sense to stay away from danger.
My father-in-law was just admitted to the hospital with lukeumia. Although this is one of the harder times in our family’s lives, it’s really been a sobering experience giving me a stronger sense of gratitude for my wife and kids.
I appreciate them more now than ever and am grateful for their health and spirit.
I wish you and your family blessings today, and pray that you too can always find gratitude, even in tribulation.
“Just hack a quick proof of concept, we’ll rebuild it when we get more funding.” These are some words I often hear from clients who have minimal budgets.
They generally want my team to build something small/quick/cheap to get their concept across in hopes of securing more funds down the road.
What I have learned by saying “yes” to these types of requests in the past is, those quickly hacked prototypes often end up in production.
While this is not necessarily a bad thing, it’s sometimes problematic if we viewed the code as disposable up front. Normally, a client will have you ship a prototype and then will want to quickly iterate. If you are not careful, you will soon accrue technical debt and eventually sour your relationship with the client due to underperforming.
So, if you are ever asked to do a quick prototype, do yourself a favor and treat it as if it will be production-ready from day one. You never know how long you will be supporting it.
I always receive cold emails. Some of them are personalized, and some of them are robotic. Sometimes, I’ll ignore and sometimes I’ll respond with something snarky (this is my spiritual gift). I get it. These are just part of the internet.
Whenever I get a cold email from someone local, it’s a different story. I always feel sorry for them. They have totally missed an opportunity to connect with someone in real life and possibly a sale.
These are the emails in which I’ll generally reply with some practical advice.
If you are desiring to cold email people in your area
Rather than emailing “Dear Brandon, I really think your business could benefit from our website services.”, you should always do at least 5 seconds of research.
Start by saying “Brandon, I really loved your post on Staying Fit With 3 Kids, I’d love to buy you coffee and pick your brain”. This shows you are interested and care about them at a human level (which you should anyway) and greatly increases the chances of them buying the services you are selling.
At worst, you will have connected with a likeminded individual who could/would potentially refer others to you in the future. At best, you could get all of the above plus a new customer and friend.
So, the next time you are cold emailing someone who’s within driving distance from you, give this post another read and consider a more personal approach.
It's been around 3 weeks since I started blogging every weekday. This experience has been nothing short of delightful.
While I have seen many improvements in my communication (written and verbal), I believe the best benefit is around the community.
When I started blogging in 2008, my posts used to have upwards of 100 comments. Granted I was a renegade blogging about iOS in a time of Apple's dreaded NDA. I absolutely loved the feedback and the community that was forming around my writing. I have been blogging on and off since then and have never felt that same spark.
This all changed, when I made a commitment to writing daily short-form blog posts and posting them to micro.blog and twitter. I began to receive comments, and these comments turned into real discussions.
This has been a blast as I'm now able to connect with so many wonderful people in the community. We are sharing thoughts and ideas and challenging each other’s beliefs on tech, business, etc…
So, I challenge you. If you are on the fence, just stop worrying about the quality/frequency/etc… of your writing and just write. And once you have written, share it with others. I promise you, the community you will build is worth it!
I was recently listening to Episode 344- 10 Strategies To Be Happier Through Gratitude on the Tim Ferris Show. Oddly enough, I much prefer episodes where Tim is absent. I do love him, but sometimes feels he steals the conversation.
Anyway, the episode was hosted by a guy named A.J. Jacobs. Jacobs wrote a book on gratitude and is known for traveling the world to thank over 1,000 people involved in his morning coffee (think farmer, roaster, truck driver, etc…).
While I loved the episode, there was something super interesting that I took from it. Jacobs keeps a notebook where he writes down just one thing that he takes away from every book, podcast, and blog.
I love this idea. Often, I will read something, get super inspired, only to forget about it and never apply it.
I feel that this is a great strategy and think it will make for an interesting post on this blog every so often. Think of it as mini book/podcast/blog reviews that highlight what I found to be important.
So my “one thing” from that episode is to start writing down the “one things” from other pieces of media.
I had the amazing opportunity today to hit File -> New Project today. There are few feelings in the world as great as the optimism that comes from starting a brand new project.
“This one will be different”, I murmur to myself. “I will keep it clean, organized, and free from hacks. “, I cheerfully gloat.
Why is it that it’s so hard to follow through on this philosophy? I said it yesterday, coding is hard. Requirements change, clients change, and most notibly, we change.
“End of the project Brandon” is usually cursing “Beginning of the project Brandon” for using some library, not commenting his code, or lazily failing to follow best practices.
But not this time, oh no. This time WILL BE different…
(follow up post to come in 3 months making fun of this one)
I have been building software for clients for over a decade now and have come to one solid conclusion: deliveries suck.
Maybe I'm just the worst developer in the world and have worked with the worst teams and have had the worst clients… but I doubt it.
I have delivered early, on time, late, with more functionality, exactly the same, and in some cases less functionality (usually due to lack of funding) and still…rough deliveries.
When I say “rough deliveries”, I usually mean angry clients and stressed out developers. Maybe not angry like the hulk (though I have seen it), but at the very least, passive aggressive comments, notes of disappointment, etc…
The reason deliveries are hard is because of a misalignment of expectations. When a client has an idea in their head of how their product should look/feel/function and it's been burning in their mind forever, us developers are doomed from the get go. We can never deliver perfectly to match this magic piece of software that only exists in our client's mind.
Also, software is hard. It's especially hard to get exactly right on the very first pass. Software is a living and breathing entity that needs lots of care and feeding. It's very tricky to articulate this to someone who doesn't understand that and is paying you 10's of thousands of dollars to build their dream.
We follow a pretty strict agile process, so the client usually sees their build at every…single…stage. They also have full control to report issues, make changes, etc… during the build cycle. Still, for some reason, they are always dumbfounded when it comes time to ship.
So, if you are building for clients, cut yourself some slack. Know that deliveries will be tough and most of the time, there is nothing you can do to prevent that.
I was having a conversation with my dad the other day and sharing some of my current business ideas with him. I also mentioned that I often discuss new product/business ideas in public with other people.
His response was obviously “Why would you just give away your ideas?”. I then proceeded to give him the "Your Ideas Are Worthless Without Proper Execution” spiel.
So, to put my money where my mouth is, I will be sharing my business ideas here; putting them out there in hopes that either a. I get valuable feedback/encouragement or b. someone else builds it and I get to use it.
So many people have RVs that are in use roughly 5% on the year. The other 95% of the time, they sit in disrepair and usually cost the owner money to store them.
While many sites like RVShare exist that allow you to essentially "rent out" your RV, they still pose a huge challenge in that the RV must be physically located on the owner's property.
I propose to build an RV storage facility where owners receive the following:
- Free Storage
- Free basic upkeep
- Free cleaning
- Profit Sharing
In exchange for this, they allow us to rent their RV out at a price we set. It would function much like RVShare in that would-be RVers reserve one of the RVs we have in our fleet and come pick it up. The RV would be ready to go with a full tank of water, full propane tanks, and a generator.
Once they return the RV, it gets cleaned and prepped for the next renter. Profits from the rental would be shared with the RV owner.
There you have it. I'd love to hear your thoughts and I hope to be sharing more of these in the future.
When I was in high school, I used to think computers were for nerds. I was a skater obsessed with chasing girls with no time for computers.
It wasn’t until a buddy of mine convinced me to take a Visual Basic 6 class with him, that I realized that I was one of those “nerds”.
Quickly, I fell in love. The first “app” that I ever completed was a game that raced various animal sprites found online using a random number generator. We all placed actual bets on the outcomes of the races. Even the instructor got involved.
That was almost 16 years ago. It’s hard to believe how much has changed. Now I just build gambling apps on the blockchain instead of VB (I’m kidding, sort of).
No real point to this story other than that I’m reflecting today on my career in computing. I’m so grateful for that friend who introduced me to coding and I’m so grateful that this career path exists.
I hope you know how lucky you are too.
Rates are a weird thing and chances are, yours are too low.
I spent years stressing about rates. I would always start strong and but then eventually get talked down (usually by myself).
I think rates go hand in hand with impostor sybdrom. “Why would anyone pay me that much”. It took me quite some time to over come this, however after many years, and multiple rate hikes, we are doing more business than ever.
Raise your rates, now. You are worth it.
People often tell me things like "it must be nice to work for yourself”, or “I'm working hard to make someone else rich".
Having spent many years working for a company prior to starting my own, I can honestly say I would never want a boss again. However, I that doesn't stop me from frequently daydreaming about just how nice that would be.
The idea that having someone tell you what to do, give you a set schedule, allow you to clock out at the end of the day all sound so liberating. Contrast this with potentially long (unpaid hours), angry clients, flakey employees, and surprise tax bills, working for "the man" doesn't seem all that bad.
There's obviously another side to this coin as well. I even wrote a whole post on this topic.
I guess what I'm getting at is, the grass truly is greener on the other side. Working for yourself has its advantages, but there are also some clear benefits of working for someone else. If you want to work for yourself, do it, if you are happy and fulfilled in your job, great.
The only way to lose is to continue down a path that no longer brings you joy.
A few years back, when the company was growing particularly quickly, I made a decision to hire my friends. Although, I had been warned by many others that this was a bad idea, I was sure that I was going to do things differently.
I was going to have a management layer over my closest friends and then they could have the uncomfortable conversations should they arise.
Needless to say, this strategy worked for a time, however at some point, things got tough and I had to make some serious decisions. I had to lay-off my buddies.
This was one of the toughest few months of my life. There was hurt and heartache all around despite my (and their) best efforts.
Working with your friends is absolutely great, until it’s not. We were all fortunate to make it out on the other side and are closer than ever, however things could have easily swayed in another direction.
So, please don’t ignore the advice that I did. Keep your friends and business separate, you will all be much happier in the end.
If you are a mobile developer in 2018, and are not consulting (at least on the side), you are missing out on a huge stream of revenue.
In the early days of mobile app development (2008/2009), it was fairly easy for an iOS or Android developer to get a gig with large companies (Food Network, ESPN, huge list of other names…). At that time, mobile was so new, that none of these companies had internal resources to support this budding vertical.
Throughout the next few years, mobile would sky rocket and all of these companies would hire internal teams to support their products.
This shift caused a huge disruption for mobile agencies who in the previous years were turning down $200+/hour because they simply didn't have the capacity. Many of them had to downsize or close their doors altogether. I was a part of one such company and have seen these shifts during the past 6 years of running mine.
I now believe the cycle is coming back around as there is a need for good mobile developers. The truth is, mobile is hard and there is a lot of competition in the space. Companies are discovering that they can't just hire a "full stack" dev and tell them to build a quality mobile app. It requires a lot of dedication and understanding of the ecosystem. Also, many of the small-medium consultancy in the space have since closed their doors. So supply is down and demand is way up.
I do however feel that the way in which consultants engage with companies has changed a bit. In previous years, most companies were interested in consulting teams / agencies to build their entire solution for them. These days, a "staff augmentation" model seems to make more sense.
In this model, consultants specializing in a vertical of mobile join other teams that lack a particular senior resource. This is a win-win for everyone as a consultant can attain consistent work and a company can hire temporary developers to solve their current problem at hand with no long term commitment. As a mobile developer, if you establish enough of these relationships, you are set on work for the foreseeable future.
We have seen this model play out many times over the past couple years and it has been key (for us) in surviving in this “post-agency” time of mobile app consulting.
So, if you are a mobile app developer (and are particularly good), I'd encourage you to branch out and try your hand at consulting. It's a great time.
I have been obsessed with Seth Godin lately. I've been reading his books, listening to his podcasts, and devouring his blog posts.
It's amazing how he can just pump out wisdom day after day and speak so articulately on just about any subject. Some of his posts are incredibly insightful while others might seem like a small thought that just popped into his head. He doesn't seem to differentiate the two and that's incredible.
Recently, I was inspired by a particular post called The First 1,000 Are The Most Difficult. In it, Seth talks about blogging every single day. He even links to other readers/bloggers that took on the same challenge. This particular quote really stood out:
Even if no one reads your blog, the act of writing it is clarifying, motivating and (eventually) fun.
This got me thinking. I often want to create blog content because I absolutely love writing. Not to mention, I really do feel that I can speak more clearly and articulately having blogged consistently. However, I often won't publish posts (or even start them) for fear of people actually reading them. It's usually a worry about what others might think about the post, or fear of peers/clients reading into things that might be tangentially related to the article in which I'm posting.
So, all that being said, I want to try to blog more consistently. Hopefully once per day. That obviously might mean quality of posts might go down for some posts, but hopefully it will increase overall as time goes on. My wife and I have recently been blogging weekly on our site about our School Bus Conversion and it's been a total blast. I'd love to apply some of that here and talk more about consulting, the business of app dev, etc…
Blogging should be for the author first and foremost, as a way to communicate their thoughts and sharpen their own skillset. Not to mention, it should be fun! I am going to try and embrace this and re-discover my love for writing.
So feel free to subscribe, unsubscribe, or drop me a note. I'd love to check out the blogs of others who are blogging near daily. Cheers!
Seth Godin recently discussed in an episode of the Tim Ferris Show a fear many of us have of the future. He used the example of him landing speaking gigs in which he was more apt to compromise and take gigs he didn’t particularly want on months in which no gigs were currently booked.
As someone in the consulting space, I can absolutely identify with this. In the past, I have taken clients in knowing very well that they will mostly be problematic (funding, difficult, or otherwise). This was out of fear that work might dry up any minute. I know this fear is unfounded as work has consistently come in over the past 6 years of running my company, however sometimes it still creeps in.
Do you deal with this kind of fear. If so, how do you overcome it?
I just had a realization that I’m a professional dream crusher. Being in software consulting, I hear multiple pitches every single week for all sorts of different software. While it’s not necessarily my job to tell people what’s good and bad, I feel it’s my responsibility to at least give them all of the information I can.
In my many years of doing this, I have learned a bit about what works and what doesn’t and I have gotten pretty good at saying no to projects that I don’t believe in. This often means crushing the dreams of someone who has a product idea that keeps them up at night. I always try to be encouraging and present them with some solution, however often times after having a discussion with me, folks will not go forward with their product development.
I often wrestle with this and wonder if it’s my role to help protect these folks by sharing my thoughts or adopt a philosophy of “the money is green either way” and accept their project. I’d be curious if others had this same challenge.
I have always loved the C programming language. I remember being a young programmer (man that was 15 years ago) when I wrote my first C program. It seemed like absolute magic (and it still does).
Since then, I love (re)discovering the language every chance I get.
I found this post incredibly well done with some great examples. I wish we had resources like this "back in my day”.
Over the past few months, I have had the pleasure of working on a DApp called thisorthat.io built on the Ethereum network. It has been an absolute blast. I have had so much fun building the smart contracts as well as the React front-end interface.
I truly believe there is a huge future here, and it can be especially lucrative for developers/startup teams. If you look at Dapp Radar, you can see that many of the top DApps have less than 1,000 DAU (daily active users). If you consider how much money is being made, crypto-users end up being much more valuable than users on any other platform.
Take for example, Crypto Kitties. It's basically a mix of Beanie Babies and Tamagatchis. According to DApp Radar, 380 ETH (or $255K USD) has moved through their platform in the past 7 days with only 652 daily active users!!!. This is absolutely insane.
It's not all sunshine and rainbows though. After spending 80+ hours working on a crypto-centric app, I believe I have some insight into some pain points that will need to be solved before these types of apps are to be widely adopted.
In my next post, I will discuss some of the hurdles preventing DApps from going mainstream. There is so much room for improvement and innovation in this space, I feel that all devs should be looking at crypto like we looked at mobile dev in 2008.
To the moon!
tl;dr: micro.blog is pretty cool.
I have recently been thinking about my process of blogging / tweeting / facebooking / etc.. and have realized that I’m burnt out on all three. I LOVE to write. I started one of the first successful iOS Blogs, published numerous (software development books)[http://manning.com/trebitowski], and have been blogging since 2008. Here are a bit of thoughts about the various platforms and ultimately my solution.
Having over 4,000 followers on Twitter I used to find tremendous value in the platform. There was a time when I would ask a programming question and get 20+ responses within 10 minutes. I’m not sure if legit people have stopped following me or have stopped using the platform, but I am no longer getting any engagement. I probably have like 20 followers and 3,800 spam bots at this point.
To me, blogging has always had to be long-form. Maybe it’s just my wannabe Tim Ferris mindset, but this has held me back from writing for quite a long time. I would wait until I had a long (usually 1K words +) post before writing anything. So, it other words, perpetual writers block.
Don’t even get me started. I jumped on the #deleteFacebook bandwagon months ago.
Recently, I discovered Manton Reece’s new platform called http://micro.blog. I guess the platform isn’t necessarily new as he launched in 2015, but after using it, it still feels like it’s in the new/exciting phase.
Manton describes perfectly why he created the platform here and this captures my thoughts exactly on the content-creation ecosystem.
Here are some things that I’m super excited about the micro.blog platform:
- You post to your own site, keeping all the content controlled by you
- You can also pay $5 monthly for a hosted blog. This means their business is built on an actual product rather than advertising revenue.
- It’s built on RSS. I have always been a huge RSS fan and am glad to see a resurgence.
- It’s full of developers that I already know/admire. Guys like @manton, @collin, and @gruber.
- It’s incredibly social. The platform really encourages conversation.
- No follower count. This is arguably the best part. No one (including yourself) can see your follower count. This allows you the feeling to just create and not worry about the vanity of the whole thing.
I still plan on using Twitter to some extent, but my primary source of content publishing will/should be this blog. It will become a mix of my long-form posts and my “tweet-sized” snarky comments.
If this sounds even slightly interesting to you, def check it out and follow me on here or on micro.blog.
In 2008, I was still in college. I had just landed my first job with a small consultancy as their first iOS developer replacing their outsourced Ukrainian team. Within my first week on the job, the CEO asked me to jump on a sales call as the technical lead. This absolutely terrified me. I remember doing things like ensuring that I had a full glass of water so my throat wouldn’t get so dry (it still did). I also stumbled over my words, almost costing the team many sales. Eventually, I learned.
Since that day, I have taken hundreds of software sales calls. Each time trying to improve my process by testing out what works and what doesn’t. Now that I run my own company, I have found that one of the most beneficial things that I have done is implemented a standard call flow.
There is a reason that call centers require their employees to memorize call flows. When you have a call flow in place, it does a few things.
1. It allows you to practice and refine your pitch over and over again.
Practice makes perfect. Definitely cliche, but it makes a lot of sense here. As you give your pitch over and over again, you will start to pair it down to something that works for you and your team.
2. It builds confidence
Many people are nervous speaking to strangers. Software developers are no exception to this. As I mentioned above, I was terrified on my first few sales calls. This had a lot to do with the fact that I was ‘shooting from the hip’ and just trying to make things up as I went along.
Once I finally got a script in place, I was able to lean on it during future calls. This gave me the confidence that I was gathering all of the right information and representing myself in the best way possible.
Now when someone says “Could I see an example of your work?”, I can quickly shoot them a link or list rather than nervously trying to get the words out “well…uh…I made an app about catz, and I’ll find the link and…uhhh… send it to you later…”.
3. It’s so easy a ‘sales guy’ can do it
This is the part that I’m starting to experiment with. I want my pitch for my company to be so tight, that I could give it to any ‘sales guy’ to deliver and him represent Pixegon in much the same way I would. I have already done this with some of my engineers as I don’t always have time to make every single sales call and it has proven to be a huge success.
4. It removes emotion
This is a big one. When we are nervous, we tend to say dumb things. I remember a few times on sales calls when I was nervous (often because I really wanted/needed the contract), that I would seriously compromise on my rate just because the client suggested it. Had I had a call flow in font of me, I would have been better prepared to field such a request.
I now replace emotion with process and it usually ends up better for both parties.
Here is a rough outline of my sample call flow:
- Client Introduction - Ask the client about their background
- How did you find us? Good to find out what advertising channels are working
- Give my background - This is to establish credentials so they trust me
- Ask the client to give a 10,000’ overview of the project - Be careful here, they love to get in the weeds
- The 3 most important questions
- What’s your budget? This will let you know right away if you want to continue much further based on your budget tolerance and rough guess on how much the above will cost.
- What’s your timeline? Every single client will say ASAP. But really this is to find out if there are any conferences, holidays, etc… that are hard deadlines for them
- How are you funding this project? Self, Company, VC, Family, Startup, etc… This will also help you assess risk.
- Ask more detailed questions about the project (If timeline / budget are somewhat ok). Determine things like backend requirements, UI/UX, Staff aug vs full solution, etc…
- Don’t give them a $$$ estimate. They will usually ask you and it will usually cost you in the end if you give them a number here.
- If all goes well, ask them to send over any assets/wires/requirements and tell them you will follow up with a rough scope and estimate. Again, don’t estimate on this call
- Thank them for their time and let them know you will be in touch.
This is definitely a good starting point. Sometimes I will copy and paste these flows into a new document and tailor them based on the client that I am about to speak to.
Sales is something that I am constantly working on and refining. I hope to continue to share my findings with you as I learn along the way.
As developers, we hear the echo chamber on Hacker News and others shouting at us to raise our rates. We are worth it. In theory they are right, we are worth it and we should be charging an industry standard rate. However, there are some instances when it’s OK to lower your rates.
Here are 3 times when you should consider lowering your rates:
1. Building Your Portfolio
This is definitely the case when you are first starting out. If you don’t have a solid portfolio, why should a client trust you to build their project at full rate. You have no credibility and they would be better off using a large shop that charges the same rate, but has hundreds of apps under their belts.
Even if you are not just starting out, this can be a great strategy to employ if you are wanting to land a client that will “look good” in your portfolio. We have done this in the past when we have wanted to break into certain markets. We found some of the leaders in those markets, given them a killer deal (or built small projects for them) so that we were able to put their logo on our website.
This strategy has proven to be incredibly successful for Pixegon
2. Longer Term Engagements
Our overall goal is to make money and provide sustainability as indie software developers. If you get an opportunity for a longer engagement on a project you enjoy working on, this often times can be much more valuable than trying to get your full rate.
3 month gig at $125/hour VS 6 month gig at $100/hour
- 3 months * 172 hours * $125 = $64,500
- 6 months * 172 hours * $100 = $103,200
In my opinion, I would MUCH rather be working on a larger contract at a lower price than a shorter one at a higher price. At the end of the day, it’s all about the contract value and sustainabilty.
3. On The Job Training
As students of computer science, we should be able to build anything right? Well, sort of. In the past, there have been instances when clients have asked me to work in unfamiliar territory. Whether that is using a programming language I have never written in, or working in a field that I don’t know much about.
Rather than just declining these types of contracts and pigeon holing yourself into one area of practice, try giving the client a discount while you come up to speed. This benefits both you and the client. You, get on the job paid training to learn new concepts and expand your area of expertise, and the client gets their product built for a significantly lower cost.
Rates are a weird thing. I would encourage you to constantly experiment. Raise them, lower them, exchange some for equity. Find out what works for you and your clients.
Over at Pixegon, I really try to encourage my developers to have their own side projects. Often times, employers look at side projects as competition and try to own the works that their developers produce. Some will even go as far as to include this in their employee handbooks.
In my opinion, this stifles creativity and creates a feeling of contention between the employee and company.
People start side projects all of the time for a variety of reasons:
- To make some extra cash
- To learn a new technology
- To sharpen one’s skills
- Just for fun
From an employer’s standpoint, these are all great. It allows my developers the freedom to learn new things, make mistakes, and even earn extra cash. All without me fronting the cost.
While this might now sound selfish, it’s obviously a two-way street. Developers greatly benefit from this type of arrangement.
Getting started with a side project
This is one I struggle with all of the time. Sometimes it’s a motivation issue, sometimes I lack an idea, and sometimes I’m just feeling lazy and end up reading Hacker News instead due to my analysis paralysis.
The best bet is to just start. Whether your idea is big or small, stupid or world changing, just start writing some code. I try to utilize this tactic in all areas of my life from code, to writing, to working out, to minimizing, and even saving money. Once you get some momentum going, you will quickly find out what’s working and what’s not.
Here are a few Hacker News Posts that I found particularly inspiring to get you started:
Dont’ have any idea to start on? Try cloning something in one of the above posts. There are tons of ideas in here large and small and there’s plenty of room on the web for variances of differenct products. I probably stole most of this post from somewhere…
If you found this post helpful and want to hear more, make sure to subscribe to my newsletter. It’s not spammy, just let’s you know when I post.
Every single year since the beginning of time (at least since the beginning of this blog), I have resolved to “blog more”. And every single year, I have absolutely failed at that.
So, in favor of systems over resolutions, I am attempting to do something different this year. Over the holiday, I blogged 12 posts related to my experiences as an independent software developer as well as business owner that I feel could benefit the community. These share everything from selling contracts to hiring friends, mistakes made, and more.
I plan on releasing one post a month on the first Monday of every month. Given that I already have these posts written, it should be a no-brainer to blog consistently. I also intend on writing in-between posts, but at this point that’s probably wishful thinking.
If you have any interest in this sort of thing (software development consulting), then be sure to add yourself to the mailing list.
Wishing you a successful and exciting 2017.
A while back, I made a flagrant comment on Twitter about how I assumed the world worked. It was something to the effect of “The internet levels the playing field, so someone without a job is without excuse”. Not shortly after I hit “Tweet”, did I receive an array of Tweets back from people I highly respected. I was immediately humbled, and it was pointed out to me that I had a severe lack of empathy.
I’m sure I was just lamenting from a previous encounter with someone who I felt was acting entitled and felt they deserved something unearned. We tend to take situational experiences and generalize them. I’d imagine this is how stereotypes are formed. But this conversation really opened my eyes to something I had never thought about before: empathy.
the ability to understand and share the feelings of another.
As software developers, it is our job to see things from other people’s perspectives. Without practicing empathy, we end up wasting our time trying to solve problems that don’t really exist. We also miss huge niches/opportunities simply because a problem that needs solving doesn’t relate to us.
So, how can you practice and develop empathy?
First, start by listening, a lot. You can’t expect to understand another person’s perspective without fully hearing what that is. In relation to this, you need to set aside your own viewpoint or opinion. Simply, hear the other person’s point of view without judgement.
Second, go outside of your comfort zone. Spend some time with people you might not normally encounter. These could be people with opposing politics/religion/world views/etc… Another good place to start is with people who are in need. I have learned many valuable lessons from visiting soup kitchens, elderly care facilities, and mission trips to impoverished countries.
Finally, attempt to understand the needs of the people around you whether you’re in the coffee shop, grocery store, or the office. There is always opportunity to learn and to grow if you are simply mindful.
Practicing empathy on a day to day basis will not only allow you to see and solve problems others don’t, it will also make you a better human.
Will you work for equity?
After you have been consulting for any amount of time, you are bound to get asked this by a client. You may find yourself struggling to decide whether or not to take some equity or just get paid to work on the project like you normally do.
I had one such scenario a while back that I wanted to share. One day a few months ago, I was approached by a local VC in town. Our relationship falls somewhere between acquaintance and friend; let’s call him Joe. Joe has a very successful background and is one of the more wealthy people in my circle of influence.
Joe asked me out for beers to discuss a new opportunity for a mobile project. I, of course obliged and met him out. During this meeting, Joe proceeded to tell me about an application he wanted me to build that would be aimed at teenagers. The gist was:
They would create rooms and the "cool kids" could vote other kids in and out of the rooms.
The offer he made was 30% of the application ownership and profits and a small share in one of his existing startups. Given Joe’s history, I knew this would most likely be a successful endeavor, however I told him that I had to think about it. Given the nature of the app, I had some strong moral objections to creating a tool that would allow teens to ostracize each other. This didn’t quite sit right with me.
After taking a few days to think I it, I ultimately told Joe that I didn’t feel right about working on the application. He said “no worries”, and that was the end of that conversation.
6 Months Later…
Some time had passed and Joe and I eventually met up for beers. After a bit of discussion, he said “Hey, I wanted to tell you about that app”.
He then follows with “I found a college kid to work on the application and gave him the same offer that I gave you. I also had a designer do some very basic mocks of the application. While I was out on a trip to Silicon Valley, I mentioned the application to a good friend of mine at Facebook. Well, Facebook has a similar product coming out (turned out to be Rooms) and they decided to give me a quick check for $1.1mm to discontinue work on the product. I then wrote the college kid a check for $333K before he’d written a single line of code!”.
My immediate thought was “at least I still have my values”. It’s pretty funny to look back and think about how I could have made so much money so quickly. However, even if I had known the potential payout up front, I don’t believe I would have still taken the project. It would have eaten me up inside.
The takeaway of this story is twofold. First, I’d urge you to choose your compensation wisely. Before this encounter, I would always give a hard “no” when asked about equity share as part of compensation. I now take it on a person by person basis. Second, don’t compromise your morals for money. I look back on this story as a success and wouldn’t change a single thing about it.
Want to jump ship and be a software development consultant? This post will detail why this path is a much more fulfilling and safer path than a traditional job.
Early in my career, I worked for a software consulting agency. I was in my early 20’s and getting paid way more than I should. One day, my boss called me up and let me go without notice.
After interviewing quite a few developers in the consulting space, I quickly realized that this is a very common story. If you work for a company, they can usually let you go at any time for any reason. Given that this is your sole source of income, you are now in an extremely risky situation.
Contrast this with being an independent consultant. Most likely, if you are consulting you have 1 or more clients. In addition to that, you have some sort of pipeline set up. So when you lose a client, you simply pull another from your pool.
Mo Clients Mo Money
The going rate of a senior software development consultant is between $100-$125/hour. At this rate, you are looking at pulling in somewhere between $16K-$20K/month.
Working for a traditional company, you would be hard pressed to command this salary even after having 10+ years of experience. I’m not joking, kids who learned to code on Udemy in 6 months were making this while I had a salary cap of around $100K.
In the U.S. , car accidents are one of the leading causes of death among young people. Obviously, consulting can help mitigate this risk by allowing you to work from home or close to it. Therefore, further limiting your physical safety risk.
In addition to limiting safety risk, not having to commute has financial advantages. Since going independent, my family has cut down our need to a single vehicle saving us money on car payments, maintenance, gasoline, insurance, and most importantly time.
Flexibility Of Location
When you don’t have to work in a traditional office, you are free to work anywhere in the world. This could be coffee shops, the park, or even on a cruise ship.
I typically like working in my shipping container office (post on that in the future) or wherever my wife has chosen to take the kids on a field trip that week.
Flexibility Of Time
When I worked at a traditional company, I was required to be signed in and available from 9-5 Monday - Saturday. As you can imagine, this has a huge impact on how you plan your free time. It’s also extremely limiting when you are trying to plan a trip or vacation.
As a consultant, you have 100% control over your time. This allows you to live life more on your terms. If you enjoy staying up late and hacking until 3am, you can then enjoy sleeping in until 11.
My wife and I currently homeschool our kids. So when we want to take a trip, it’s literally a matter of leaving our house. We don’t have to ask for time off, we don’t have to plan around other people. We can quite literally drop everything and head to Disney World during the “deadest” parts of the year and enjoy doing things while others are “working”.
I have found this level of flexibility has greatly improved my quality of life.
This sort of goes with what I said above. Traditionally, if you want to take off time you need to:
- Make sure it's cool with your boss
- Make sure it's cool with your team
- Give 2 weeks notice
- Fill out paperwork
- Burn through your limited "vacation days"
- Still take calls from vacation because your are a "nice guy/gal"
When you are a consultant, the process becomes:
- Leave for vacation
You Are Your Own Boss
"So, Peter, what's happening? Aahh, now, are you going to go ahead and have those TPS reports for us this afternoon?" - Bill Lumber
I never want to have a “boss” again. It’s true. I hate the thought of someone constantly breathing down my neck watching my every move. I also can’t stand the idea of someone giving me a ”performance report”.
When you become a consultant, it should be obvious, but you are the boss. Early on, I would make the joke when my wife asked me to go on a random adventure “Let me check with my boss”. Hilarious right?
Working In Your Underwear
Unless you are a Victoria Secret model, chances are you actually have to put on pants to go to work. Not with consulting! I’m so glad I met my wife before I became a consultant, otherwise there would be no chance of me landing her wearing some of the choice outfits I do during work hours.
I find my level of quality goes up with my level of comfort. It never made sense to me why companies preferred “business casual” over “sleep professional”. Seems like millions in lost revenue.
This list is in no way meant to be exhaustive. These are just some of my favorite perks that I have been enjoying over the years. If you have some others that I have missed, please feel free to add your comments below.
As the new year kicks off in full swing, I am reflecting on my 2015 goals and setting some new ones for 2016.
Here is how I did on each of last year’s goals:
Create a business plan - Fail. I did not create a business plan for Pixegon. This might have to carry over.
Grow Pixegon (my mobile consultancy) to 2x 2014 revenue - Success. We not only achieved this goal, but surpassed it. Pixegon did a total of $1.1mm in revenue in 2015!
Hire a “director” - Success. OK, so this one is sort of in the middle. I didn't quite hire a director per se, however I did elevate my senior employees to more management roles. This allows them to take some of the day to day tasks off of my plate.
Move to a weekly - Fail. But I'm OK with it. This isn't very important.
Morning Routine - Moderate. Some days were better than others
Blog twice a month - Huge Fail. I averaged .41 times per month.
Take off / reduce workload - Success. More camping!
Give away more than 10% of personal income - Success. Our family was blessed with multiple opportunities throughout the year to be a blessing to others in addition to our normal donations.
Overall, I’d call 2015 a success. I managed to hit the goals I felt most passionate about, and more importantly, this exercise has helped me to determine what I should focus on. With that being said here are my goals for 2016.
- Land ONE new client. Sounds crazy I know, but allow me to explain. Pixegon has been fortunate enough to work with some pretty incredible clients. Many of these clients trust us to be their primary dev team throughout the year. I intend on finding at least ONE more client like these in 2016 (Referrals welcome ;) ).
- Build Something New. As I continue to build a company, it's often hard to get back to my roots of writing code and actually creating something. I miss this. It provided so much value to me over the course of the years. So, this year, I want build some "side projects".
- Hire. I hope to grow the team by at least 20% this year. (We are always hiring most positions).
- Be more intentional about EVERYTHING. I have really been into a few blogs lately (Mr Money Mustache, The Minimalists, 4-Hour Workweek, etc...). What I have really learned is that I want to be more intentional about everything I do (Family, Time, Money, etc...). Part of this is removing my dependency on my phone, simplifying my life, and scheduling undivided time for the things that are important.
- Stop Complaining. I read this incredible book called A Complaint Free World . He talks about the power of Not complaining. This has really resonated with me.
- Blog Twice Per Month. OK This time I mean it (1 down, 23 to go! )
- Read 5 books. Arbitrary amount I know, but I need something measurable.
That’s it. Here’s to a healthy and productive 2016!
Feel free to link me to your 2016 goals blog posts in the comments.
It’s late, you have been hacking all night to get the client a build. Finally, around 2:30 am, you hit submit and publish something to the client and go to bed. When you wake up in the morning, the first thing you see in your inbox is an email titled “Completely Broken!!1!”.
How could this be? You stayed up late, you hacked, you tested and you sweat over this build to find that it crashes for the client when they try to do something obvious.
As developers, we often can’t see the forrest through the trees. What this means is, we get so deep into the code working on a new feature or fixes that we often don’t notice when we break things. This doesn’t mean that we are bad developers, it just means we think differently about development. It also means we can’t personally handle everything.
However, from a client’s perspective, failures like this can really tarnish your brand. They start to get the impression that you are unprofessional and even worse, start to doubt your abilities as a developer.
QA (short for quality assurance) is an idea that someone other than the developer tests the build before the client ever sees it. These people are responsible for
- Regression testing (as in the scenario above)
- Generating a test plan/matrix
- Ensuring parity (if needed) between multi-platform applications
If the QA team is doing it’s job, the client won’t every see these obvious failures mentioned above. This can greatly improve the client’s perception of you/your team.
OK, QA sounds great, how do I get started? Well, it’s actually relatively simple. First off, I assume you are doing some flavor of agile, and hopefully logging tickets for each task. If not, you should (even if you are a one man show). Here is a rough flow that my team follows:
- Developers determine which tickets to work on for the current sprint
- Developers complete a ticket and move it to a “dev complete” column in the task manager (Jira, Trello, Pivotal Tracker, etc…)
- Developers deliver a build internally
- The QA team takes the build and goes through their testing matrix to check for regressions.
- If a regression is found, a bug ticket is created for the responsible developer
- New features are added to the QA test matrix and tested
- If the feature has bugs or doesn’t work as intended, the ticket is rejected and pushed back to the developer
- Once everything passes, the build is green-lit to be sent to the client (usually one build per sprint)
Like anything, you may develop your own version of the above, however this should be a detailed enough outline to get you started.
In my experience, clients will generally give you some pushback when you say that you are billing them for QA hours. They will say things like “It’s OK, I can test the build myself.” or “I understand, things won’t be perfect. We will through this together”.
While this all sounds good at the surface, the fact of the matter is, it almost always will end unfavorable. The client might have some level of tolerance early on, but as you start sending them more and more builds, each potentially missing/breaking features, they will become less patient. I have seen this happen plenty of times even with the most tech savvy of clients. Here are a few ways you can build QA into your billing process:
Add it as a line item
This is where you will most likely see the most opposition. Make sure to explain to the client that their time is valuable and you don’t want to waste it. Also, ensure that the cost of QA is drastically less than the cost of engineering or you will get questions like “Why am I paying you full price to test?”.
Be sure to tell the client that QA is just part of your team’s process. You simply don’t operate any other way as you know that this is the best approach for both parties. Hopefully, this will establish your expertise in the domain and the client will respect you for that.
Bake it into the cost of engineering
Often times, you may not bother with too many line items. You may just have something like Engineering $200/hour. When/If the client gives any pushback about cost compared to other shops, simply inform them of all they are getting inside of that hour (Engineering, Consulting, QA, Project management, Office management, etc…). It actually works out to be a much greater value for them than paying say $125/hour for a “code monkey”.
I absolutely believe that QA is crucial to the success of any software agency or freelancer. Not only does it allow you to come across as more professional, it also helps keep you sharp as a developer. While I’m not suggesting QA is a silver bullet (I still believe in Unit / Automated testing), I feel that everyone should at least have some layer baked into their process.
There is a familiar phrase that I hear all too often when a client comes to me with an existing application. It goes something like this:
“Our team spent quite a bit of money on our application and we don’t want to ship it. We are not proud of the product.”
It blows my mind that many developers and development teams are still in business given the poor quality of products that I see getting churned out all of the time.
When I encounter these types of situations, I immediately know that the team (or individual) behind them is much more interested in a ‘quick buck’ instead of the longevity of their company. Poor quality in software is directly related to cutting corners.
A few examples of cut corners:
Using inexperience developers without proper guidance. I am all for hiring ‘staff’ level developers, however, they must be properly mentored and trained so that there is no compromise on quality. If you must compromise on something, compromise it on time.
Outsourcing the project without proper guidance. Although I don’t prefer outsourcing given the communication challenges, I am not opposed to it. There are plenty of talented individuals all over the world. However, given the varying degree of abilities and communication issues, one must not rely 100% on an outsourced team to ship a product.
Not following coding standards/guidelines. This could be things such as: not commenting code, not testing, not leveraging a QA team, or simply writing “smoke an mirror” code.
I can usually identify immediately which of the above applies after spending a few minutes with the code. In fact, I have built much of my business around saving these types of projects.
So I urge you, although it might cut into my market share, *please *build something you are proud of. This is not only the right thing to do, it is also **critical **to your future success as an independant software developer.
During my years of mobile development, I have heard the phrase “I have an idea for an app!” hundreds, if not thousands of times. Sometimes it would be from family members, sometimes my dentist during a cleaning, and sometimes from a naked dude standing in the sauna at the gym. Everyone pitches app ideas to me.
What I have learned from hearing so many pitches is this: apps really fall into one of three (sometimes four) categories. Allow me to elaborate.
1. The app has been done before
This is the most common category of app idea I hear. Usually, these are along the lines of, “It’s like Instagram, but for finger painters…”, etc… where the user takes an already proven idea and tries to tweak it in some way that they feel makes it new. Most of the time, these people have not even done any research to check as to whether or not a solution already exists.
The biggest hurdle in developing an app that has been done before is visibility; How are they going to get people to find the app and why should they choose it over the competition?
2. The app idea is too niche
Every now and again, I will hear a truly unique idea. Keep in mind, unique does not necessarily mean good. For example, I might hear, “I want an app that you can take photo of your cat, put it on a weather balloon, and send the balloon to space. ‘Catz In Spaze!’”. While this is unique, and technically feasible, one would be hard-pressed to make a real business out of it as it would be hard to get enough users on board to make it profitable.
3. There is a reason the app does not already exist
“I want an app to map out all of the grocery stores layouts in the world, so husbands can finally shop efficiently!” This is a great idea. It really is. So great, that I have literally heard it no less than ten times from various people over the years. Often times, I can predict when someone is about to pitch this particular idea, just by the setup: “You know how, like, shopping is hard, and like, you can’t find stuff…”.
There are some real technical hurdles surrounding this problem. While there are a few apps that have tried to solve it, no app will really accomplish the goal unless they have all of the following: total store participation, a large enough group for crowdsourced data, faster and more reliable GPS to know exactly where you are in the store, stores stop changing layouts, etc… You get the idea. There are a lot of reasons a solid solution for this does not exist.
There are other countless examples of app ideas falling into this category. Another fun one I get pitched is a killer app that converts any photo into a (caricature) [http://en.wikipedia.org/wiki/Caricature]. I’m sure someone will link one in the comments, but they are all mediocre at best.
Bonus #4: The app is used to augment their existing business
This is actually my favorite type of app to work with. The user has an existing business and wants to build something that benefits their business in the mobile space. I see ideas from evaluation tools for employees to apps that allow users to order products directly from the business.
I like these because the success of the business does not depend entirely on an app. Also, there is generally an audience built right in at launch time so everyone is happy.
I am not writing this post because I’m jaded and sick of hearing app ideas. Quite the contrary. I love hearing app ideas and would love to hear examples challenging the stereotypes that I have created here.
I give this spiel to clients from time to time and wanted a place that I could point them to, so feel free to send your clients to this post the next time you get the grocery store mapper pitch.
It cannot be overstated that writing down one’s goals is critical to acheiving them. Pair that with sharing them with others who might help keep you accountable and your probabilty of achieving those goals goes way up.
With this in mind, I have decided to share my 2015 goals here on my blog in hopes that I will do a better job of acheiving them in the new year. I tried to focus on more measurable goals rather than things like “eat better” and “exercise more”.
So, here they are in no particular order.
- Create a business plan
- Grow Pixegon (my mobile consultancy) to 2x 2014 revenue
- Hire a “director” to help with oversight of current developers
- Move to a weekly rate instead of hourly
- Be consistent with morning routine
- wake up early, pray, blog, mediate, read Bible, write down MITs,
- Blog twice a month
- Grow the blog’s mailing list
- Take off / reduce workload on Friday’s to spend the day with my family
- Launch Autumn Village
- Give away more than 10% of personal income
This list is definitely not complete, however it’s a good start. I hope to refine it over the coming months and more importantly, stick with it.
What are your 2015 goals? I would love to hear about them in the comments or via email.
One of the most common questions I get from software consultants is whether or not to accept fixed bid contracts. In this post, I’m hoping to shed some light on fixed bid vs. time and materials contracts and help you make the best decision for the project at hand.
Let’s start with some definitions to help you better understand what I am talking about.
A fixed bid contract is a contract where the developer and the client agree on a price and/or timeline up front for a particular contract. If additional time is needed, there must be some sort of change order issued to and signed by the client.
A Time and Materials contract is a contract where the developer and the client agree on an hourly rate for the development of a project. While there should be some initial estimates up front, the developer is not locked into a certain number of total hours/dollars. If more time is needed than stated in the original estimate, the developer has the freedom to continue as the client’s budget (and patience) permits.
Below, I’ll compare and contrast the pros and cons of both fixed bid and time and materials contracts. Note, this is just from my experience and your experience might vary. In fact, if it does, I’d love to hear about it in the comments.
Fixed Bid: Pros
You can potentially make a lot more money.
If you are a good estimator (or a bad one and the client accepts an overbid), then this is your chance to get paid whatever you want to get paid per hour. If you bid 100 hours and get it done in 50, you have essentially doubled your rate.
- *It’s easier to manage the pipeline.
*Generally, when you do a fixed bid contract (again assuming you are decent at estimations), fixing a contract allows you to plan out more contracts ahead of time. Typically the fixed cost comes with a (roughly) fixed timeline. This allows you to project future availability for yourself to work on other projects.
You know what you are building up front.
*If you have done your due diligence (gathering requirements, specking things out, etc…) there should* be no surprises. Everything is already laid out for you and if the client wants to change anything, it will require a change order.
- *You are selling value instead of time.
*This is actually a hot topic lately. Many will argue never to sell by the hour as so much more goes into your rate than just time (your knowlege, history, expertise, etc…) The client wants to pay your for a solution to their problem and that’s infinitely much more valueable than your time.
- *It’s sometimes easier to land contracts.
*Some clients have a very specific budget. If you can provide a solution to them inside of their budget, then the contract is yours every time.
Fixed Bid: Cons
You can potentially lose a lot more money.
There is a joke that goes something like this: There are only 2 hard problems in software development, knowing when to expire a cache and accurately estimating working. Generally, the overzealous developer will error on the side of too few hours in order to ‘land the contract’ or ‘please the client’. This usually results in the developer bidding 50 hours and realistically working the 100.
Clients WILL feature creep. Feel free to tweet that or write it on your forehead. It’s just a fact of life. You, being the super nice developer that you are, will want to please the client and will say something like “it’s outside of scope, but I’ll make an exception”. Before you know it, the app has pivoted and you are building things WAY outside the scope of the initial contract.
Can I…? NO! Well, what about…? NO! Just This… NO, NO, NO!
With a fixed bid contract, if you are an experienced developer, you will ALWAYS be telling the client NO. If you are wondering why, see #2. While feature creep creates a tension, so does not allowing the client to change course, if needed.
- *It’s sometimes harder to land contracts
*If I take a fixed bid contract, I generally error on the side of overbidding. This allows padding for things like QA, small changes, App Store submission, etc. Given the high bid, your client might baulk at the contract and attempt to outsource to India himself, where he will eventually spend double.
Time And Materials: Pros
- *Your work is always compensated
*Given that you are getting paid per hour, you can always count on a steady stream of revenue coming in. This is very comforting to developers since you know you will always get paid the rate you want for the work you do.
- *Landing contracts can be easier
*Clients don’t always know what they want up front and the idea of not committing to a certain dollar amount is sometimes comforting. It also gives them MUCH MORE freedom to make changes and pivot down the road.
- *It gives clients the freedom to prioritize features
*This is one of the biggest selling points that clients appreciate when I sell a time and materials contract. Given that my team follows a version of the agile development methodology, clients love that they have some insight as to how much each feature roughly costs. They can see the estimates and translate that into cost. If they feel a less important feature is too costly, they can prioritize the backlog to get more (less complex) features for the same price.
- *Less Risk
*Since you are only selling the client your time, you don’t necessarily owe them anything except work. Most of the time, time and materials contracts don’t even have an official scope of work attached.
Time And Materials: Cons
- *It doesn’t scale
*You can never make more money than your time will allow. If you charge $100/hour and work 40 hours/week, then you can never make more than $4,000/week unless you work more.
- *You are a commodity
*The client doesn’t so much look at you as someone who is providing them a solution as they do a “resource”. You are perceived as less valuable and therefore could easily be replaced.
- *More Risk
*I know this type of contract is listed as less of a risk above, but there is also some riskiness to it. If you get in the weeds on a task or start introducing too many bugs, the client might feel that you are misleading them or incapable of performing and you risk getting released from the project.
While I have only scratched the surface in comparing these two types of contracts, I hope you have a better understanding about which route to pursue for you. My advice is to not be too rigid stating “I’m only going to use contract type X forever” because each contract situation may vary. Use your best judgement and make the decision that is best suited for each individual project and client. At some point in the future, I will post a few tips for making this decision based on some factors, but that is for a later date.
Until then, happy consulting!
P.S. Make sure to sign up for the newsletter below to be notified about awesome posts like this in the future!