brandontreb.com Tips And Resources For Software Consultants

Your App Idea Most Likely Falls Into One Of Three Categories

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.

Conclusion

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.

 

 

 

 

Goals For 2015

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.

Professional

  • 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

Personal

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

Software Consultant Contracts: Fixed Bid VS Time And Materials

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.

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

  1. 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.
  2. *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.
  3. 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.
  4. *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.
  5. *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

  1. 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.
  2. Feature Creep.
    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.
  3. 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.
  4. *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

  1. *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.
  2. *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.
  3. *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.
  4. *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

  1. *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.
  2. *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.
  3. *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.

Takeaways

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!

Software Development Consulting: Some Tips On Structuring Your Contracts

When I first started out as an independent software developer, one of things that stressed me out the most was how to structure contracts that I sent to clients.  Working for a consultancy in my previous work-life I had seen contracts before, however, I never really paid enough attention to them to know what type of content went into them.

After quite a bit of research, I found an invaluable resource.  Over at techrepublic.com, Chip Camden posted a beautifully crafted consulting contract template.  You can see the post and download the template here.  This post was a lifesaver.

Chip goes over EVERY single section of the contract and gives an explanation of why it’s there.  You can download the template and determine which sections you need for your business, based on his explanations.  It doesn’t get much easier than that.  Of course, I would still strongly suggest you fork over a couple hundred bucks and have a lawyer look over the contract before sending it off to clients.

How To Sign Contracts Online

Once you have your contract in place, you will need a way to get your clients to sign it.  You could go the old-fashioned way of scanning, both parties signing, and scanning again OR you could use an online signature service.  One that I use and highly recommend is RightSignature. I know those guys personally and have had a great experience with the service so far.

Here is my process:

This is what I have found works out well for my business.  #proTip: I have my assistant do this now 😉

  1. Complete the contract blanks in regards to rates or any other information you want the client to see before they sign the contract.
  2. Upload the contract template to Google Drive (optional).  Make sure your company info is completed and all of the other fields (dates, signatures, etc…) are blanked out.
  3. Once inside of your RightSignature account, you can connect to your Google Drive and import the document in.  You can also upload them directly from your computer if you don’t want to use Google Drive.
  4. RightSignature lets you put text fields and date boxes in the blanks and specify who is responsible for filling them out (you or the client).
  5. Finally, add the signature fields at the bottom and send off the document for signing.
  6. Once every party has filled out the needed information, the completed document is then sent to both parties via email.

Other Considerations

Often times, the client will have their own contracts for you to sign.  This isn’t necessarily a bad thing.  However, make sure that you read over it carefully and run it by your lawyer.  Don’t try to force your contract on a client that already has their own.  They will usually not be open to this, in my experience.

Make sure to have an ‘exit clause’ in your contract in case things go sour.  I seldom enter into fixed bid contracts so I usually have a clause where either party can cancel the contract with 7 days written notice.  This also makes the client feel at ease as they are not trapped with you in an event where their situation changes.

Finally, be willing to be flexible.  Sometimes clients might not like certain clauses in your contract.  Be willing to change things like delivery dates, invoice dates, invoice periods, rates, etc… on a client to client basis.  Obviously, use your best judgement here.

Conclusion

I hope that you have found this post useful and it saves you some time hunting down a contract template.  I am always open to suggestions so if you see anything else that works for you, I would love to hear about it via email or in the comments.

Please consider signing up for my email list to get killer posts like this one delivered to your inbox.

*Disclaimer: I am not a lawyer and do not claim to be giving any real legal advice.  I am simply stating how I do things with my business.  Make sure to consult with a lawyer before engaging in any contracts.

Being An Indie Software Developer And Signing NDAs

Very frequently, I receive emails that go something like this:

“Hey Brandon, I have a killer project idea. Do you want to work on it?  Please sign the NDA so we can talk.”

Early on when I first started consulting, I would have responded with something like “Sure send it over!” and signed the thing without hesitation.  As of late, I have changed my view on NDAs; at least in this type of situation.

For those that don’t know, an NDA (non disclosure agreement) is a contract that is intended to protect the intellectual property of the client.  They make a lot of sense, especially in the event that the deal goes sour.  Say a client has some great idea for how to better take selfies that is going to revolutionize the selfie game.  If he doesn’t get a developer to sign an NDA, the developer could potentially be free to discuss the idea with others, leaving the idea open to be stolen.

Why I Don’t Sign Preliminary NDAs

In the scenario I mentioned above, it would be very unwise of me to sign this NDA as I don’t have enough information about the product.  This puts me as a consultant at a huge risk.

Say for example I am working on a photo/video sharing app (I get roughly 1 request a week for some spin on Instagram). Now, say the incoming project is some variant on photo sharing. If I sign the NDA, it now now puts me in a conflict of interest with my existing project.

Even if I knew that the project was a photo/video sharing application up front, I still would not sign the NDA.  Much of the time (as mentioned above) clients want very similar applications.  If I went around signing every single NDA that came across our desks, I would be out of business after the first client.

When I Will Sign NDAs

Well, the first thing that I do is ask for clarification on the project and tell them my NDA policy.  I basically tell them that I am happy to sign the NDA if one of the following conditions are met:

  1. There is extremely proprietary information (you can’t land a big enterprise contract without first signing an NDA)
  2. We are ready for project kickoff and all parties are aware of any potential conflicts

In addition to that, if I am currently working on a project that is of similar type, it would be worthwhile to disclose that information to the potential new client (not the proprietary info, just that there is some overlap) so that they can choose whether or not to proceed.  Better to possibly lose the new client than end up in a crazy legal battle.

If the new client refuses to give you any more information, then they are not worth your time.  They will most likely be too challenging to work with down the road anyway.

NDAs Are Not Set In Stone

When you do finally decide to sign the NDA, know that it is not complete until you sign it. If you see something that you don’t like or want to add any additional clauses, feel free to propose those to the client.  Most clients will be very understanding.

That being said, it’s VERY IMPORTANT that you read all the way through an NDA and possibly run it by your lawyer before signing.

Suggestion If You Want Your NDA Signed

If you want a developer to sign your NDA, make sure to give him enough information about your project for him to make an educated decision.  If you just say “I want a photo sharing app” and expect an NDA signed, good luck.  Make sure that they know there is proprietary information involved and that you are doing something different that must be kept private.

An NDA is not required if you want to make say an “Instagram Clone For Puppies” or a “Miley Cyrus Flappy Bird Clone”.  Be sensitive to the uniqueness of your idea and decide if it really warrants an NDA.

Also note that developers are not out to steal your idea.  They get pitched hundreds of ideas and most of the time your idea falls into 3 categories anyway:

  1. It’s not unique
  2. There is a technical challenge and that’s why it hasn’t been done (I get pitched a lot of ‘Map a grocery store so that my list will navigate me around’ ideas)
  3. Your idea is so niche and so unique that the general audience won’t get it and it won’t be profitable anyway

I’m not saying that every idea falls into these categories. But a good majority do. Most of them fall under #1 and that’s not necessarily a bad thing.  Google fell into #1 and look where they are today.  Just keep these things in mind when requiring a signed NDAs before you will give out any info.

Conclusion

There has been quite a bit of discussion lately (especially on Hacker News) about whether or not to sign NDAs.  Most of the recent articles I have read are simply titled “I Will Not Sign Your NDA”.  I feel that NDAs have there place, but you should sign them only with extreme caution.  Examine each NDA on a case by case basis and determine how it will affect your business in the long run.

*Disclaimer: I am not a lawyer and do not claim to be giving any real legal advice.  I am simply stating how I do things.  Make sure to consult with a lawyer before engaging in any contracts.