Do’s and Don’ts of Running an Application Development Business

Running an application development business can be very daunting. Especially if you don’t establish some guidelines for yourself. It’s important that you map out what you want out of it and where do you want to take it in the future. Of course, you can’t possibly map out every detail of your plan but you can create somewhat of an outline to go by.

In this article, we will talk about the high-points of that outline. I’m a firm believer that there is no secret to success in business, just core concepts that make up the basic structure of one.

Although this article is geared toward an application development business the principles here can be applied to other industries.

DO: Step Back and Look at The full Picture First

Before you start printing and handing out business cards, take a step back. With a wide-angle lens look at the whole picture. What do you want to get out of your business in the long run?

Some other things you might want to consider is what sort of clientele do you want to attract. Develop small utility applications for small businesses or full-fledged enterprise apps for large corporations.

Determine what tools you will need, hardware, software. Using open source development applications is usually the most economical way to go. However, depending on the full realization of your vision you might decide against that. Either way, it’s a good idea to consider all of these things before setting out on your journey.

DO: Take On Projects That Utilizes Your Strongest Skills First

This one should be obvious, for some, it’s not. Some people want to focus on projects that require the latest or most popular technologies. That’s a good goal to work toward but maybe not at first.

When you’re starting out, clients simply don’t know you yet. They don’t have any past projects to gauge the quality of your work. So don’t dive in and use a technology that you are unfamiliar with. It’s ok to turn down some projects that might require technologies you’re not very versed in.

This is by no means taking the easy way out. You are starting with a comfortable footing so you can do the best possible job for your client. Once you do this and begin to adopt other technologies your clients will see your potential for growth and expansion. Don’t worry if you start out struggling a little with new stuff. Your clients will be more understanding because at this point they’ll have a good track record of your work.

This is not to say that you absolutely should not start with technologies that are less familiar to you. If you are comfortable with quickly adopting and utilizing new technologies efficiently then keep on rocking. If not, just take baby steps, you’ll get there soon enough.

DO: Create A Development Standard Early On

If you do this, your future self will thank your past self. Seriously, adopt a development standard early. There are tons of books on this but at its core, it’s simply common sense and thinking ahead. Still, you must be balanced. There’s no way to predict where your product will be 400 iterations down the line. If you notice your code starting to look a little like spaghetti, stop!. Step back, and re-evaluate, refactor, make adjustments to your standard.

Your standard won’t be perfect at first. In fact, it probably will never be perfect, and that’s ok. It’s a work in progress so don’t over analyze this at every step. Your goal here is to make sure code and documentation are efficient, readable and understandable by others and by yourself months, even years down the line.

DO: Plan Out Each Project For Weeks Before You Start Coding

For goodness sakes don’t just start coding right out of the gate. Sure, you’ll get a working application fast but at what cost? What usually happens in a situation like this is you keep building on top of a thrown-together code base. As a result, you get a Frankenstein of an application that’s difficult to maintain.

Plan it out, draw some pictures. Walk-through what the client would see and do, carefully craft the user’s experience. Next, design the data and function independently of the actual interface. This will help you better design what the interface will look like.

Once you get some of those details ironed out, start putting together some “proofs of concepts”. These are typically micro-projects that helps “prove” parts of your application will work as designed. The point of all this is to build your application on a solid foundation. This will help ensure that you don’t spend months building something only to have to ball it up throw it away and start over.

DON’T: Be Afraid To Start Over If It’s Going Very Badly Early On

If you notice your project going down a very dark road early on, stop, and regroup. Look at where you are, where you’re headed, and where you’re trying to go. If something just doesn’t look like it needs to you may need to change directions or scrap the whole thing right there.

I’m not suggesting to scrap it when things don’t go your way. Use your best judgment, you’ll know if it’s bad enough to scrap and start over. It takes time and effort to learn the difference between something that can be salvaged and something that needs to be thrown away.

All in all, don’t be afraid to take that action and do it sooner not later. If you wait too long you might become too invested and need to retain and build on top of the poorly designed code base.

DON’T: Try To Do Everything Yourself

When you’re passionate about something it’s easy to get caught up in trying to make sure every detail is perfect. I understand, trust me, I feel the same way about many things that I work on. I have also learned that going down that road can quickly burn you out.

You might go from being the visionary of a company to wearing too many hats and not being good at any of the jobs. Yes, you absolutely should keep a check of your entire company which should be done from a more elevated position. Once you start delegating work don’t micromanage everything they do.

If this happens you’ll be in even worse shape than before. Only now, you’ll be paying people to do a job and you are the one doing it. Sounds silly, doesn’t it.

DON’T: Let Your Clients Create Deadlines For Your

I get it, your clients are very important. After all, they’re paying for a service and you want to do a good job as you should. This is one of the reasons you don’t let them create your deadlines for you. It will be more difficult for you to do a good job for them if you miss the deadline by a long shot.

Or, in my opinion, a much worse outcome would be to produce an inferior product just to finish on time. This could result in diminished trust in your company as a whole. You don’t need that. Especially not in a startup or a young company on the rise.

True, deadlines are going to exist. However, your deadlines should be carefully set and discussed with all members of your team and your clients. In addition, you should create milestones in-between your goals to help everyone involved stay on task and to be informed of changing conditions.

DON’T: Sell Yourself Short

Last but not least. Don’t sell yourself short. Your skills took lots of time and effort to acquire so you should be paid what you’re worth. On the flip side of that is obviously don’t oversell yourself or change an absurd amount of money.

For this, you need to do a little digging and self-reflection. Here are some things to consider when coming up with prices for your services:

  • Cost of your application development tools.
  • Make your desired hourly rate more than what it would be if you worked for someone else.
  • At first, you probably won’t be paying any employees. But you should consider the cost and build it in so you don’t have to have such a drastic increase in price when you do.
  • Think about how valuable it is for your clients to have an application that works exactly as they want it to.

There you have it, a short, but concise list of do’s and don’ts in building an application development business. So now, head out into the wild blue yonder. Or green, purple, or whatever color that represents the dev-tools or target platform you’re creating your applications for.

Leave a Reply

Your email address will not be published. Required fields are marked *