Keeping Your Hired Engineering Costs As Low As Possible

Jeff Spinella
Leaders of Marketing
4 min readDec 23, 2016

Do Your Own Design and Get an M.V.P. Out the Door A.S.A.P.

There are basically two components to “creating” any mobile application or website: design (the appearance) and engineering (the moving pieces behind the scenes that make it all go). Let’s break these down a little bit further:

Design

At DarwinApps — like many other engineering firms — we have designers that we can work with at our clients’ request. However, we generally encourage our clients to perform their design work in-house.

The reasons for this are two-fold:

  1. Cost Reduction: Design is a highly iterative process, requiring extensive visual edits and back and forth discussions (this can get expensive with a contracted vendor).
  2. Sensory/Experiential Intimacy: Design is highly intimate for whoever is creating the product, as it’s the visual portal through with users/clients/everyone else views your brand or product.

Depending on the above two variables, a simple design for a single web page or app can take a designer or designers anywhere from a couple hours to a couple of weeks or even months, for certain larger projects. The design time for an average sized website (and group of 10–15 pages) or app (with 10–15 screens) is likely around a few weeks or more.

Though design isn’t directly related to “engineering-costs” per se, it’s certainly a factor in overall cost. And the less work that‘s contracted out, the fewer iteration and feedback loops needed with a contracted designer at an agency or engineering firm, the lower your overall cost will be.

Engineering

One simple but functional web page (yes — only one page) built with WordPress can be churned out in 1–2 days by a decent developer. Sounds like a lot, right? Think about the feedback iterations it can take to get one page just right.

This means that an average website, with 10–15 pages, would take 10–30 work days (2–6 weeks), not including any feedback rounds or optimization for mobile (which generally requires a ~30% time multiplier).

(As noted in last week’s article, A mobile app can take anywhere from 100–5000 total hours to be built, and the average website anywhere between 50–1000 total hours.)

For the lowest cost to clients, we at DarwinApps always insist on fixing time and budget while having a flexible scope in order to get an M.V.P. out the door, which can be iterated on and improved in time.

In plain English, this means that the design and functionality of the site or app must 1.) have a hard and fixed launch date and engineering budget, and 2.) must allow for enough flexibility in design/function implementation in order to meet both of the time and budget requirements.

Building a product with a million bells and whistles can lead to wasted engineering hours on functionality that may end up being useless (or unwanted from users), and eliminates any sort of A/B testing/user feedback period, the most valuable tool and stage for determining how to best align what your product provides with what your desired audience wants.

For example, let’s say a company launches a new site with 5 distinct pages, and 70% of traffic goes to page 3, with the rest of the pages getting 30% split among them. This is an indicator that more time after launch would be best spent building greater functionality/animation/etc. on the 70% page, something that would have been unknowable prior to launch. And this avoids the error in spending a massive amount of time on building a page that will receive next to no traffic.

The Bottom Line: Dollar Signs

Summing up, here are 6 ways that the plan laid out above (In-house design, fixed budget, fixed timeline, flexible scope, M.V.P. out the door ASAP, iteration/testing after launch) can keep your engineering costs at a minimum:

  1. Allows for huge savings on potentially very expensive design work, which can free up more budget for engineering hours where desired.
  2. Allows you to set exactly how much you’d like to spend from the start on getting a baseline product delivered. This also allows for budget planning for any iterations/added functionality that you will want post-launch.
  3. Prevents you from wasting engineering hours before launch on excessive iteration and/or features or functionality which may be unnecessary or unpopular with users.
  4. Allows for more organic testing and feedback with users after launch instead of costly engineering testing pre-launch.
  5. Provides valuable information on working with the engineers that build your M.V.P., including the quality of product they can build and how well they work with you/your team. If you’re unhappy with the team and/or product, you’re free to go somewhere else after launch to improve on it instead of investing your entire budget with a vendor that may not work out (the fewest “locked-in” hours necessary).
  6. Faster launch=quicker opportunity to earn revenue or business through your product, which gives the added benefit of more budget flexibility for continued iteration, functionality, and/or features.

Being as efficient, strategic, and as least wasteful as possible will always minimize the chance of negative outcomes along the way for your project.

On Mobile? Click here to sign up for our newsletter.

--

--