Office: 270.245.1188 Emergency: 270.752.0059
Site Contents

C O M P A N Y

Overview
Advantages / Blade's Edge
Personnel
Contracts & Rates
Contact


S E R V I C E S

Software Engineering
Systems Analysis
Networking & Security
Repairs & Upgrades
Training & Support


P O R T F O L I O

Overview
Landmark Projects
Government Projects
Non-Profit Projects
Development Tools
Scientific & Technical Projects
Support & Business Tools
Consumer Products
Company Contracts & Rates
 
Jump To:  Overview |  Structures |  Deliverables |  Changes |  Ownership |  Support |  Payments
 
 

Most of us would rather not think about contracts, but we all know they're necessary for everyone's protection. As explained below, software development contracts are unlike any other, though they're probably most akin to those in construction. In fact, the similarities between these two industries are reflected in the common expression "We're building software to [insert function here]" and its various offshoots.

The most important thing to keep in mind when contemplating our contract framework is the timeless business adage "Everything is negotiable." While we will initially suggest a particular, basic contract structure based on scope, requirement-certainty, and other project-specifics, we'll find a way to work within whatever contract format makes you and your company most comfortable.

 
 
Basic Contract Structures
 
Jump To:  Overview |  Structures |  Deliverables |  Changes |  Ownership |  Support |  Payments
 
 

Software development contracts generally conform to one of three fundamental types:


T I M E   A N D   E X P E N S E

Also known as time-and-materials, this is the most common contract structure, and one with which we're all familiar: The client pays an hourly (or in rare circumstances, daily) service rate, and reimburses the developer for materials, third-party employment, and other expenses required to complete the software. Although used in a variety of situations, if the client is sure of what he wants but the developer is highly unsure how long it will take to deliver, the project will be billed on time-and-expense.

From the client's perspective, the advantages are:

  1. Work Begins Quickly

    Because the developer doesn't have to provide an exact project cost, up-front requirement-gathering and research is less-comprehensive, and engineers can "jump right in."

  2. Few or No Quality/Time Compromises

    Because the developer isn't rushing his work due to budget caps hanging over his head, he can produce software in which even the most minor functions are exceptionally-built.

  3. No Unknown Charges

    Because all costs are line-itemized, clients know exactly what they're being charged for. The only possible question on the client's part becomes "Why is this taking so long?" which we all ask when we're not familiar with the intricacies of another person's profession. When posed this question, developers are happy to answer in far greater detail than any client ever wants to know. ;-)

The only real disadvantage is nevertheless a significant one — cost. The client has little budget-control. Devlopers, by nature, want to make the best product possible. If left to their own means, they tend to "gold-plate" their work, enhancing it beyond specification. Of course, as long as they're monitored and managed well, this won't happen

Even so — like construction — software development is almost never without some unforeseen, non-trivial complication, so it's likely that the costs of a time-and-expense project will somewhat exceed initial expectations. You'll have some excellent software to show for it, though!

Even though the client assumes nearly all the risk, time-and-expense is still the most common type of contract because everything else falls in the client's favor.


F I X E D - C O S T

In this structure, the client and developer agree on product specifications, then the developer prices the job. This structure is most often employed when the client's vision for the software is underdeveloped and its budget limited.

From the client's perspective, the advantage of this type of contract is simply that The developer assumes nearly all the risk. The client can rest easy knowing that the cost of working through any unanticipated problems is of no concern to his company. The developer must deliver what was agreed on in the design phase.

Disadvantages are as follows:

  1. Delayed Work

    Because the developer must determine overall project cost with utmost accuracy, an exhaustive design phase — including requirement, data, logic, and integration-specification — precedes the writing of even the first line of code.

  2. Quality May Suffer

    Occasionally, a project goes sideways — and thus, overbudget. Even when the development company is determined to hold itself to exemplary standards, some individual developers feel self-imposed pressure to cut corners. People generally try to avoid distressing their bosses. It's just human nature, and even nerds and geeks are human.

  3. Changes Increase Cost

    Regardless of how carefully and thoroughly the up-front design process was executed, as clients see the software take shape and begin making more concrete connections between it and their business processes, they discover that they didn't know exactly what they wanted after all.

    Clients always want changes, and because this contract model puts initial requirement- and cost-determination squarely on the developer, the expenses of client-spawned changes are the sole responsibility of the client. Generally, the later in development that changes are requested, the more they cost.


C A P P E D - B U D G E T

The least-common contract structure, cappped-budget contracts are also the most balanced in terms of risk-sharing. By choosing this model, the client and developer are essentially agreeing that neither of them have enough information to assume the majority of the risk imposed by time-and-expense and fixed-cost contracts. Thus, this model is selected when the client isn't certain of non-core requirements and the developer suspects that some portion of the non-core requirements will be unusually esoteric or demanding.

An abbreviated up-front design phase is employed to enumerate core requirements and as many secondary features as can be reasonably-defined. The two parties agree that the developer will work to implement as many of these prioritized requirements as possible within the budget. As work progresses, the requirement-fulfillment are constantly reevaluated against the remaining time/budget to allow for course corrections and maximize success.

From the client's perspective, the advantage of this model is that project success is guaranteed: The developer guarantees that basic functionality will be achieved without cost-overruns. In a world where countless business and technical projects never see the light of day, this is a major benefit.

The disadvantage is simply that the client may experience a certain degree of disappointment if the resulting software doesn't include as many features as he'd hoped. As is so-often the case, it's expedient to keep expectations in-check.

 
 
Phases, Deliverables, and Deadlines
 
Jump To:  Overview |  Structures |  Deliverables |  Changes |  Ownership |  Support |  Payments
 
 

P H A S E S   A N D   D E L I V E R A B L E S

Projects are divided into distinct stages, usually referred to as phases. For all but the smallest projects (in most of today's methodologies), the development phase is further subdivided into deliverables or milestones.

A deliverable is a usable but incomplete version of the application. Each deliverable meets a particular, growing subset of the overall project requirements.

Deliverables allow the client to incrementally test functionality, and both the client and developer to get an instantaneous, bird's-eye view of the project state. The earlier that bugs and design flaws are detected, the less the monetary and time-costs to fix them. Therefore, it's beneficial for everyone if the client commits to allocating resources for testing of deliverables.


T H E   R E A L I T Y   O F   D E A D L I N E S

For as long as people have been paid to write software, there's been a ubiquitous expression used as a retort whenever a non-developer attempts to impose a "hard deadline" on a developer: "Software is done when it's done."

Business managers often bristle at this expression: They don't understand it because they work in different worlds. Drop a line in a status report or a business plan or a project proposal, no one is likely to notice; drop a line in a computer program, and the whole thing comes crashing down. It doesn't do what it's supposed to do. It blows up, or generates or records errant data, or otherwise makes a mistake. It's better to think of software like a profit and loss statement or a balance sheet: Omit a line-item in one of those, and the entire report becomes unreliable. (Of course, profit and loss statement-generation is semi-automated and highly-predictable, so the analogy only goes so far.)

Add, to this hard truth, client-spawned specification-changes, integration hassles, faulty and unreliable client-infrastructure, new technologies, component updates by other software makers, and innumerable, other unknowns (as we call them), and pinpointing a completion date becomes far more witchcraft than science. Thus, "software is done when it's done." It doesn't mean we don't make every effort to provide the most accurate estimates possible, it just means that no eyebrows are raised when delays occur. Delays are part of the business.


D E L I V E R Y   D A T E S

A delivery date may be tied to each deliverable. However, each date should include a bonus clause, as mandating deliverable delivery dates effectively turns one project into several, removing much of the give-and-take the project manager has to work with in order to complete the finished product on-time, not to mention increasing stress by an order of magnitude.

There's just so much that can go wrong in software development. Studies vary, of course, but typically show that 60-70% of projects across the industry don't meet their target completion dates, never mind their milestone dates. (Our is much better than that. ;-)) Add a bunch of intermittent deliverable dates to the requirements, and it makes our lives much more complicated.

For this reason, it's more common to leave delivery dates unspecified, instead naming a target project completion date with a single bonus clause if early-delivery is beneficial to the client's business.

 
 
Specification Changes
 
Jump To:  Overview |  Structures |  Deliverables |  Changes |  Ownership |  Support |  Payments
 
 

T H E   R E A L I T Y   O F   C H A N G E

As previously indicated, client-requested changes are simply inevitable. As the software takes shape and clients begin to see it in action on-site, they realize that their stated requirements weren't as accurate as first thought. Don't panic: Developers have learned to expect this.

However, the reality is that nearly every change from spec costs time and money. Even if a feature whose spec has changed has not yet been implemented, other parts of the program that interact with this feature may be affected. Engineers must expend precious time to accurately determine both the intended and off-target effects.

As an illustration, think of a design change as a stone dropped into a body of water, and the its ramifications as surface waves propagating across the surrounding area in all directions. While not every change carries such consequences, the potential for them typically lurks beneath the surface, and is usually far greater than appears at first blush.

Worse — as with bugs — the later in development a design change is made, the more time and money it costs to implement; and while the cost may not grow exponentially over the course of the project, it's certainly non-linear.


C H A N G E - R E Q U E S T   P R O C E D U R E

To address these issues, we've developed a formal procedure to handle change requests:

  1. The client submits the request   in writing   to our project manager. We provide a template for this.

  2. Our project manager reviews the request and calls the client to clarify any murkiness. Often, this conversation will be centered around quantifying the projected/targeted/imagined benefit(s) of the change.

  3. The manager assigns the request to an engineer, who researches and determines the feasibility of the change, what and how other systems are affected, the overall risk, and the total time involved.

  4. The engineer's findings are returned to the manager, who again calls the client for discussion. Eventually, the manager and client agree on a course of action based on the objectively-identified costs and benefits.

This process ensures that every change request is documented, researched, evaluated, and judged based on as much hard evidence as possible.

 
 
Source-Code Ownership and Licensing
 
Jump To:  Overview |  Structures |  Deliverables |  Changes |  Ownership |  Support |  Payments
 
 

L I C E N S I N G

Unfortunatley, almost every first-time client believes that because their company is paying us to write code, it owns the resulting program. Nothing could be further from the truth.

As many traits as the software industry shares with the construction industry, ownership is definitely not among them. Code is intellectual property, and therefore rightly-governed by an entirely different set of laws than is physical property.

By law, the moment a line of code is written, it is copyrighted; and by law, unless otherwise specified in the development contract or in an a legally-binding transfer of ownership, that copyright belongs to the developer.

Like all software — including the off-the-shelf, shrink-wrapped, mass-marketed variety — the purchaser is buying a license to use the software, not the software itself. Our standard license basics are as follows:

  1. The licensee has the right to use the software indefinitely, i.e. there are no "subscription" or "renewal" fees.

  2. The licensee has the right to install the software on as many systems as they like, and to use the software simultaneously on as many systems as they like.

  3. The licensee has the right to require Blade Technologies to deposit the source code in escrow. Blade Technologies will update the escrow-based source code at client-agreed intervals.

    In the event that Blade Technologies becomes insolvent or otherwise unable to make paid modifications to the code for purposes of maintenance, enhancement, or extension, the escrow service will release the source code to the licensee. In this case, both the licensee and Blade Technologies are permitted to make modifications to the code and to sell, re-brand, or reuse it in any way desired, short of any non-disclosure or non-compete agreements.

    The escrow company is to be selected by the licensee and approved by Blade Technologies, which — at the licensee's request — will provide a short list of recommended escrow companies with experience in source-code escrows. Payment for escrow services is entirely the responsibility of the client, as it is the client that benefits exclusively from the services.

Blade Technologies retains ownership code written for the client, and is thus able to modify, repackage, reuse, and resell it as part of other products. As independent software developers, we actually count on this right to provide business value in future deals.

Therefore, if a client wants all or part of the application to be exclusive to the client company, we are happy to negotiate that provision for inclusion in the development contract, but it will come at a price, depending on the amount of code and on our estimation of its future revenue-generating capabilities.


N O N - D I S C L O S U R E   A G R E E M E N T S

On the other hand, we understand that companies need to keep proprietary algorithms, formulas, trade secrets, partnership information, employee information, and user data private. We willingly sign and comply with non-disclosure agreements, and never disseminate any information that the client has not previously and publicly disclosed.

This doesn't mean that we won't use general descriptions and non-exclusive screenshots of the products we build for your company as promotional tools. How else would we ever build a portfolio? We assure your that we review every word and every picture to ensure that no NDAs are violated: We'd want the same from our clients if positions were reversed.


N O N - C O M P E T E   A G R E E M E N T S

Non-compete agreements are another matter: Many non-competes are so broad-ranging as to be legally-unenforceable. In fact, we've been presented some that were positively unilateral, and just downright looney. If a non-compete is topically, geographically, and time-limited, we're happy to sign it; but if taking one job is likely to hamstring us from generating future revenue streams, we'll just politely shake your hand and walk away.

Successful business relationships are most-often built on shared risk and shared benefit: Bully-level non-compete agreements shift all the risk to the developer and all the benefit to the client.

 
 
Warranty and Support Options
 
Jump To:  Overview |  Structures |  Deliverables |  Changes |  Ownership |  Support |  Payments
 
 

L I M I T E D   W A R R A N T Y

During the first post-launch months, we want the costs of fixing any programming defects discovered in our software to fall on our shoulders. Therefore, every contract includes a ninety-day, limited warranty. This provides ample time for any insidious, chameleon-like issues to be uncovered via normal use of the software.

Warranty basics, in plain English:

  1. If the software doesn't do what we agreed it would in the specification, we will fix it.

  2. If the GUI doesn't match the specification, we will fix it. This does not include any minor cosmetic differences, such as rounded-corner controls vs. angled-corner controls.

  3. If a reliably-reproducible error or errant behavior occurs, we will fix it. If it's not reliably-reproducible, we will give it a hard look, but it's insanely difficult to fix what can't be reproduced on-demand.

  4. If a reliably-reproducible crash or lock-up occurs, we will fix it. Again, if it's not reliably-reproducible, we'll give it a hard look.

  5. Problems occurring while using the software on or against hardware other that used for testing are not covered by the warranty. In this case, a paid support option is required.

  6. Problems occurring while using the software in a manner other than that described in the specification are not covered by the warranty. In this case, a paid support option is required.

  7. Data damage, loss, or corruption occurring while using the software is not covered by the warranty. In this case, a paid support option is required.


S U P P O R T   O P T I O N S

Beyond this warranty period, we offer a variety of support contract and pricing structures to accommodate every client and every situation:

  • Hourly Rates

    This pay-as-you-go option is the most economical choice in many cases, as our software requires minimum support beyond the initial ninety-day warranty-period. It is billed in fifteen-minute increments, and covers all tiers.

  • Standard Support

    This is our standard, flat-fee plan based on the number of software users and on whether we are expected to provide Tier 1-3 or Tier 2-3 support. (The latter is a lower-cost plan.) Guaranteed response time is four hours. Support is limited to business hours, which are 8a-6p M-F. Holidays are not included.
  • Priority Support

    This is our premium, flat-fee plan based on the number of software users and on whether we are expected to provide Tier 1-3 or Tier 2-3 support. (The latter is a lower-cost plan.) Guaranteed response time is one hour. Support is provided 24/365, including holidays. In essence, we operate as if we were "on retainer" with this plan, and thus its cost is considerably greater than other options. For situations involving mission-critical software, however, it provides peace-of-mind and can save thousands in operational losses.

All options include on-site support at our discretion.

Plans for multiple software products can be combined, with the first plan billed at full price and all additional plans at half-price.

 
 
Payment Structures
 
Jump To:  Overview |  Structures |  Deliverables |  Changes |  Ownership |  Support |  Payments
 
 

We understand that every business has its preferred methods for handling billing, and that small businesses, in particular, have complicated cash-flow situations. Therefore, we're very flexible when it comes to terms of payment:

  • Time and Expense Contracts

    We prefer to bill on a bi-weekly or monthly-basis, with payments due ten days after invoice delivery.

  • Fixed-Cost Contracts

    We prefer 15% down, 15% at each of three milestones or 20% at each of two milestones, and the balance — including any overages due to client-spawned changes — on final delivery.

  • Capped-Budget Contracts

    We prefer 15% down, 15% at each of three milestones or 20% at each of two milestones, and the balance on final delivery.

Beyond these terms — and in the right circumstances — we will consider profit-sharing in lieu of part or all of our fee.

However, if these terms don't work for the client, others can be negotiated. We'll even entertain proposals featuring non-standard contract structures. We want to make it as easy as possible for your company to use our services.

 
 
[Back to Top]