Tips for Planning Your Software Development Budget

Handling budgets for software development projects is a challenging feat. The traditional approaches used for years are becoming increasingly obsolete, making it difficult to accurately plan your department’s production monitoring budget and all the other essential pieces required to build an effective application that keeps up with customer demands. Figuring out how to manage all of these complexities successfully is a challenge.

Generally Accepted Accounting Principles

Before exploring the ins and outs of budgeting, let’s take a quick look at some of the key financial principles and accounting rules. The Generally Accepted Accounting Principles (GAAP) are widely recognized in the United States and serve as the guidelines for proper accounting practices. Following GAAP standards helps executives and investors make long-term financial decisions.

GAAP follows a handful of assumptions, principles, and constraints to accomplish its goals.

Assumptions

• Business Entity: Your business is a distinct entity whose revenue and expenses differ from those of its owners or other organizations.
• Monetary Unit: All financial records are kept in a specific monetary currency. The US dollar is the assumed monetary unit for GAAP and most US-based organizations.
• Periodicity: Your business’s economic activities can be divided into arbitrary time periods (e.g. fiscal quarter).

Principles

• Historical Cost Principle: Instead of fair market value, your company must report the costs of assets and liabilities at the time of purchase. However, most debts and securities are reported at market value.
• Revenue Recognition Principle: Your business must record revenue when it is earned rather than received. On the flip side, losses must be recorded when their occurrence becomes “probable,” regardless of whether the loss has already occurred.
• Matching Principle: Revenues and expenses must be matched to one another when reasonable to do so. As such, expenses are recognized when the work resulting from said expense contributes to revenue.
• Full Disclosure Principle: Your company should provide enough information in its disclosure documents to make decisions on that information and keep costs reasonable. There needs to be a balance between providing more information, which increases associated costs, and the amount of relevant financial data included in the body of financial statements.

Constraints

• Objectivity Principle: Your business’s financial statements must be factual and based on objective evidence.
• Materiality Principle: An item should be disclosed and considered “significant” if that item would affect the decision of a reasonable person.
• Consistency Principle: Consistency is vital in accounting principles and practices, so your company should maintain the same approach from one time period to the next.
• Conservatism Principle: When choosing between two financial decisions, your organization should choose the option that is least favorable (i.e. more conservative).
• Cost Constraint: The benefit of reporting financial information should exceed the cost of supplying said information.

Budgeting Challenges With an Agile Methodology

Organizations implementing a more traditional waterfall software development methodology can often rely on more traditional accounting and budgeting techniques. However, as modern development methodologies embrace more agile models, applying those same financial practices to an organization or constantly changing projects can be challenging.

Capital expenditures are funds that are typically used to purchase major assets or services that can improve your company’s ability to generate profit. These investments might include computer hardware, software, or a new office building. Unlike regular operating expenses, capitalized expenditures are not recorded yearly or quarterly but are treated as long-term assets. The cost is spread out over a period of time - usually between five to ten years - using a method such as depreciation.

On the other hand, operating expenses cover all the ongoing expenses required to run your business, including payroll, employee benefits, rent, transportation, etc.

Things get a bit more complicated for software development organizations, particularly during agile development life cycles. For most US-based businesses, according to the Statement of Financial Accounting Standards No. 86, “all costs incurred to establish the technological feasibility of a computer software product to be sold, leased, or otherwise marketed are research and development costs” and “shall be charged to expense when incurred.” Proving that your product is “technically feasible” requires that your organization has completed all “planning, designing, coding, and testing” necessary to meet the software’s design specifications and technical performance requirements.

Once production begins, however, the “costs of producing product masters incurred after establishing technological feasibility shall be capitalized.” That is to say after you’ve proven your software is technically feasible, all production-related costs (coding, testing, etc.) can be considered capital expenditures.

Finally, after your software is released to the customer’s production environment, all capitalization of costs must halt. Moreover, costs of “maintenance and customer support shall be charged to expense when the related revenue is recognized or when those costs are incurred, whichever occurs first.”

In other words, the actual period in which your team is developing and producing the software can be capitalized, while all other costs (including those for post-production maintenance and monitoring) are considered normal operating expenses.

Calculating an Overall Software Engineering Costs

Many of the standard accounting and financial practices used by the FASB — and via GAAP — can often be a bit outdated, particularly as they pertain to the rapidly-changing realm of software development. For example, the Statement of Financial Accounting Standards No. 86 document we examined in the previous section — while generally applicable to software development organizations — was originally published over 30 years ago in August 1985.

To cope with modern business practices, the FASB occasionally releases updated standards documents. One such document is Intangibles — Goodwill and Other Internal-Use Software (Subtopic 350-40), which covers the accounting practices for cloud computing arrangements and was published in April 2015. This document outlines some critical accounting scenarios such as software as a service, platform as a service, infrastructure as a service, and so forth.

One such intangible asset that is crucial to a robust and well-supported application after release is production monitoring software. Coming up with the appropriate production monitoring budget can be difficult, but the newer standards and accounting guidelines linked above can help. Here are a handful of tips to get you started on overall budgeting, which will help you determine your organization’s production monitoring budget.

Identify Your Key Decisions

Start by brainstorming a list of decisions you want to make with this budgeting process. A few examples might be:

• Begin development of project X or not?
• What is the budget for project X?
• Is it time to start advertising?
• Are we ready to launch production?
• How will we monitor our application after launch?
• With the critical decision points in hand, you can move onto the next step.

Break Down Software Features

Next, make a list of all the major features the application should have. For example, a tic-tac-toe knockoff might require:

• Players
• Turns
• Winning/Losing
• UI
• Art
• Music/Sound
• Leaderboards
• Cloud Syncing
• Production Monitoring

And so forth. All these features should be high-level concepts at first, but from each concept, you can start to break it down into smaller, more tangible pieces of functionality.

Budget Each High-Level Feature

Now we select a single high-level feature and break it down as much as possible, which will allow us to roughly estimate the manhours (and therefore cost) of implementing said feature. To illustrate, let’s break down the UI component of our tic-tac-toe game:

• Launch screen
• Main menu
• Buttons
• Score
• Game board
• Leaderboard
• Dialog popups
• Text/Localization

We can dig down as much as we want, but with our component extrapolated we can estimate the manhours or weekly work necessary to complete each sub-section:

• Launch screen – 1.5 hours
• Main menu – 3 hours
• Buttons – 1 hour
• Score – 0.5 hours
• Game board – 4 hours
• Leaderboard – 5 hours
• Dialog popups – 1 hour
• Text/Localization – 6 hours

These are just made up numbers, of course, but with this estimate in hand we can start to budget for each high-level feature. In total, we’ve estimated that our UI feature will require around 22 hours of work. We can now apply our weekly operating expenses for a ~22 hour period and come up with an overall cost for this feature. For larger projects, we’d likely use weeks or even months as our time period to estimate, but the same principles apply.

Let’s imagine we’ve determined that it’ll cost us around $15,000 to operate the company over the 22 hour period necessary to complete our UI feature. We can then make note of that on the high-level feature list and, once all features are budgeted, come up with a grand total budget. We won’t bother doing so for this example, but this concept makes it easy to determine which features are within budget, and which may need to be scaled back (or removed altogether).

Final Thought

Remember that the first version of your product, project should be as simple as possible (only the main functionality). The deeper you go into development, the higher the cost of a mistake. You don't need to perfect it. The later you get feedback from users, the more expensive the mistake will cost.

As usual, we remind you that such a SaaS MVP development can be done by the joint efforts of our team for the optimal time and budget.