Efficiency: 4 Ways to Reduce the Cost and Time of Software Development

In any industry, efficiency is important. Lower costs and shorter timelines reduce risk and increase happiness. Because long, expensive projects make me think of the infamous Healthcare.gov. Having clients wait for results lowers trust. And unjustified high prices prompt the question of what that money is really buying.

 We’ve worked with many different levels of companies. From bootstrapping founders to established organizations. It’s a common question, in any industry, “how can we lower the cost?”. In all business, every smart consumer wants to stretch their dollar. We understand, and here’s the advice we’ve given to dozens of awesome clients. They appreciate it. We’ve also interviewed plenty of developers and partnering organizations. If you’re shopping around for a technical team or development firm, start here.

1. Select the right team, with the experience you’re looking for.

If you’re looking to build a garage on your house, you’re not going to search for a gardener. You have to find the right handyman. Just as there’s many different types of construction, there’s just as many different types of software development. Web, front-end, back-end, networking, databases, etc. If you’re not technical, you may not know the pieces you’re looking for. That’s ok, just ask. Front-end is what you see: it’s a website, it’s an app, it’s a desktop program. Back-end is what it does: it’s the server, it’s the database.

We’ve mentored startups, founders, and friends along the way, many who’ve asked, “how do I pick the right software developer?”. Our answer: find a firm that has done it before.

The problem is that your perfect fit isn’t necessarily the one dominating Google’s SEO results. The other problem is that most firms like to say they can do it all. Well, we don’t like to say that, and we don’t suggest it for your business either. We refer out clients that aren’t a good fit for us. We don’t want to be a jack of all trades, of every programming language, of every platform. We love our iPhones too much, and we know we’re darn good at mobile. At Jackrabbit, we don’t do games. But what we “do do” are beautifully functional business and media apps.

Digging even further. What type of app are you trying to build, and what technologies do you want to use? Are you building a social game, or a business utility? Are you using iBeacon and Bluetooth, or cameras and filters? Find a team that has experience with that technology. It cuts down the learning curve and the amount of time that team needs to spend researching those frameworks. Plus their estimations will be more precise upfront. If they know how much work feature XYZ was last time, they’ll know how much to expect next time. It’ll increase quality, if they already have practice with it, and decrease R&D time.

Is your software for healthcare, or for entertainment media? First, the design principles are different. Second, the frameworks and tools are different. Third, the architecture and data models are different. IBM doesn’t build too many games. And EA Sports doesn’t make accounting software. It’s the same reason that Lamborghini doesn’t do mini-vans.

2. Make sure the prerequisites are ready

A piece of software rarely operates completely independent of the internets ecosystems. Data sources, social media integrations, and other systems are leveraged to synergize the value of your software. (That’s the only time I’ll say leverage and synergize in the same sentence… promise.)

You can’t start building your mansion until the foundation is set. We can’t start building your app until the data is available. We’ve told clients they’re not ready yet. And we’ve helped them get ready. Then we show them how much time we saved. They love it. One of my favorite quotes is: “weeks of coding can save you hours of planning!”. It’s so true.

Startups live in the hack-a-thon mentality, “just get started!”, “fail fast!”. We’re all for that, but here you’re asking how to be more efficient. We commonly lay out iterative sprints with clients to build, test, and analyze feedback. It’s part of the process. Yes, prototype and test. But prototyping without a prototype doesn’t get you very far. And if you’re testing with nothing to test, then you sure are going to fail fast. Make sure the prerequisites are in place, and then execute.

Our team will validate any APIs (your servers that we’re talking to). We’ll make sure the expected data is there, in the expected format. We’ll make sure all of the systems are accessible. And we’ll make sure the integrations are configured correctly (Got your app id and app secret key? Are you in sandbox mode?).

“But we’re innovative, brand new! Of course these systems don’t exist yet; we’re doing things no one has ever done before!”

Awesome, we love launching new initiatives. So here’s your alternative: simulation. Dummy data; mock it up and stub it out. If you know what information is going to be transferred, then we can simulate the process. Create the API endpoints, setup the parameters and response codes. If there’s a shared expectation of what’s going to be transferred and how it’s going to be transferred, then we can take it from there. Even better if we know the structure.

For example, if we can expect the following JSON data for a user’s profile:

{“name”:”Mike”, ”age”:32, interests”:[“golf”,”music”,”cooking”]}

Then we can build the software to use that information appropriately. The problem is if the data fields and structure here changes. Then we need to rework our code. It’s like designing electrical plugs and outlets. I love traveling abroad, but hate forgetting power converters. Your data needs to flow from output to input smoothly.

3. Batch revisions.

We understand that ideas and requirements continually grow and evolve over time. You’ll get user feedback and find new opportunities. We’ll brainstorm with you, and we’ll make suggestions. We might think up a great new feature; you may make a pivot. That’s business. We love being agile, and we want to create the best product together. Because we’re on the same team, and your success is our success.

Feedback, field testing, and revisions are part of the game. That’s why it’s iterative; that’s why we’re agile. After each development build you receive, we’ll reach out and ask what you think. Do you love it? What needs to be changed? Were users confused about anything? Did the features performed as expected? This feedback, improvements, and changes are best done in batches. If you just took your car in for an oil change yesterday, have to take it back in for new brakes tomorrow, and then need an inspection next week, well, you’re making a lot of trips to the mechanic and wasting a lot of gas.

Let us batch of the feedback and revisions, and work them into our sprints. Nit-picking one change this week, and then wanting to revert it next week gets in the way of the bigger picture. If you install hardwood floors in your house, and then decide to carpet the whole first floor, well, you’re calling the handyman back over, and he’s sending you another bill.

Revisions are hard to scope ahead of time. The amount of effort to set aside, and time to budget can vary. We may just need to move a couple buttons, or we may need to revamp the whole login flow. Revisions may require re-architecting and re-modeling the database. That’s like trying to build a basement for your beautiful new house, after the house has already been built.

4. Bonus: Draft user stories and wireframes

User stories are awesome. But awesome user stories are not easy. You’re making an investment to build software, and you value professional work. That’s why you’re here. Likely you have the ideas that you want to build, maybe you have some requirements. Regardless, you have some expectations. That’s why we typically start with a project discovery phase.

Your ideas, requirements, and expectations should be translated into user stories. Development teams can be composed of designers, developers, project managers, testers, and more. User stories help all of these people communicate in a common format and understand the system. They define who will use software, what function they need to perform, and the goal they’re trying to accomplish.

I’m a fan of the following form. It gives context.

“As a     (user)      , I want to     (do something)      , so that     (accomplish a goal)     “

For example:

“As an end-user, I want to upload pictures, so I can add them to my post.”

“As an administrator, I want to monitor and delete content, so that inappropriate images can be removed.”

Next, since the day you first started thinking about this software, chances are pretty good that an image of some kind has already popped into your head. You’re thinking of a Facebook-style navigation, or maybe the cool new Twitter feature. Get that on paper, so we can both see the same picture. Sketch, draw, stick-figures; they’re great.

Plus, you’ll start thinking about where the buttons need to go, and what screens are necessary. Can users share posts? Well, we’ll likely need a Compose Post screen, Edit Post, and Post Detail (for viewing). Are there user profiles? Then it’ll likely display differently for viewing your own profile versus someone else’s profile. How about a user search menu? How do we get to that screen?

Wireframes iron out the UI/UX, and are an essential part of our process. A couple of our favorite tools are Balsamiq and Prototype on Paper. You’ll save a bunch of time and research if you already have them planned out.

Fini

Remember, all of these points depend on what your goals are. Here, we’re talking about efficiency, and these are the best options to optimize the project triangle.

Build an App Quickly and Efficiently with Jackrabbit

At Jackrabbit Mobile, our team understands the process of app development from design to launch. Our team will consider all the factors that will make your app a success to help you grow your business.

Contact Jackrabbit Mobile to turn your idea into a reality!