Office: 270.275.6510 Emergency: 270.752.0059
Site Contents


Blade's Edge
Contracts & Policies


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


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. Software development agreements are unlike any other, though they're probably most akin to construction contracts. In fact, the similarities between these two industries are reflected in the common expression "We're building software to [insert function here]."

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 requirement-certainty, scope, 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: Time-and-materials, fixed-price, and capped-budget. Regardless of the method chosen, the developer will provide a good-faith estimate including the total cost and projected completion date.

T I M E   A N D   M A T E R I A L S

This is the most common contract structure, and one with which we're all familiar: The client pays an hourly (or rarely, daily) service rate and reimburses the developer for equipment purchased for the client, project-specific tools, sub-contractor fees, and other expenses required to complete the job. It's usually chosen when requirements cannot be fully-determined or are expected to evolve during development, as well as when the developer will be working with problematic or unfamiliar technologies.

From the client's perspective, the advantages are:

  • Work Begins Quickly

    Since the developer does not (and often cannot) provide anything beyond a reasonable estimate of project cost, less time is spent on up-front research into non-critical, ambiguous aspects of the job, shortening the initial requirments-gathering phase.

  • Fixed Quality

    Because the developer doesn't have a budget cap hanging over his head, there's no need or temptation to cut corners: He can focus on producing exceptionally high-quality software that satisfies the client completely in every regard.

  • Unlimited Project Changes

    As the software starts to take shape and user-feedback mounts, the client will begin to envision the final product in a more complete and realistic form than was possible during the initial design phase. Consequently, he will inevitably want changes. The time-and-materials model enables the client to expand or alter the specification whenever and however he sees fit.

  • No Unknown Charges

    Clients always know exactly for what they're being charged because all costs are line-itemized. 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. Nevertheless, when met with this query, developers are happy to answer in far greater detail than any client ever wants to know. ;-)

Thus, while the client must manage cost and time risks, quality and completeness are assured. Like construction, custom software development is seldom without impossible-to-forsee complications, so it's not uncommon for costs of a time-and-materials project to somewhat exceed initial expectations. Of course, the client will be informed of all such issues and provided with options so that any overruns can be minimized.

Even though the client assumes the cost risk, time-and-materials is still far-and-away 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 a product specification before the developer prices the job. This structure is used only when:

  • Due to past devolopment efforts, deep investigation, or limited project size and scope, the client's vision for the software is rock-solid, OR

  • The software is to be used in a life-dependent application, or otherwise in a zero-fault-tolerance environment. In such cases, the cost of even a minor change can be enormous, as it may require an impact study and additional quality assurance procedures. Therefore, the specification is strictly defined and frozen up-front.

From the client's perspective, the advantage of this type of contract is simply that the developer assumes the cost risk. He must bear the financial burden of working through any unanticipated problems and deliver what was agreed upon in the design phase.

Disadvantages are as follows:

  1. Delayed Work

    Because the developer assumes cost-risk, he must determine overall project cost with utmost accuracy. This requires an exhaustive design phase — including requirement, use-case, data, logic, and integration details — preceding the writing of even a single line of code.

  2. Quality May Suffer

    As time and money begin to dwindle in a fixed-price project, details may fall by the wayside. Efforts will be concentrated on fulfilling the specification while underlying, unpolished infrastructure such as error-recovery, data validation, logging mechanisms, and security measures are moved to the back burner. In the frenzy of activity that builds as the developer is attempting to wrap-up the project and please the client, such non-visible, non-core components can be overlooked.

  3. Changes Increase Cost

    Regardless of how carefully and thoroughly the up-front design process was executed, clients begin making more concrete connections between the software and their business processes. To their horror, they discover that they didn't know exactly what they wanted after all. Clients always want changes, and the fixed-price model simply doesn't accommodate changes.

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

While this structure is essentially the same as fixed-price, there are a couple of major difference in workflow. As the rarest model, the capped-budget contract can even be thought of as the inverse of fixed-price in that the project cost is determined before the specification. This structure is primarily used in two cases:

  • The client and developer agree that neither possess enough certainty to assume the cost-risk imposed by time-and-materials and fixed-price contracts. Thus, they choose the capped-budget model as it is designed to mitigate cost-risk by sharing it.

    The client is a startup (or pre-startup) that has a big idea and not-so-big budget. Depending on the scope of the product and the amount of available funding, the capped-budget model will result in, at bare minimum, a prototype that can be used to promote the business and persuade potential investors to buy-in.

An abbreviated up-front design phase is employed in which the client and developer agree on the designation of core requirements. Additionally, the two parties enumerate as many ancillary features as can be reasonably defined. The developer then works to implement as many of these prioritized features as possible. Thus, core features are built first, with minor features only appearing once fundamental functionality has been completed, and then only if budgeted-cash remains.

As work procedes, project progress is regularly reevaluated against the remaining budget to facilitate course-corrections. Once the budget is depleted, development comes to a halt. Naturally, work can resume when additional resources become available.

Besides reduced cost-risk, the advantage of this model from the client's perspective is that project success is guaranteed: The developer delivers a spartan, but reliable software product created with minimal financial investment. Basic functionality is certain to be achieved without cost-overruns. In a world where countless business and technical projects never see the light of day, this is a significant benefit. In exchange, the developer receives the assurance that he won't be working for free on the homestretch, as too-often occurs.

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 hoped. As long as both parties practice expectation-management, however, this pitfall can be avoided.

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 milestones or deliverables.

Milestones can be almost anything: The completion of a particular feature or component, the processing of a certain data set, the submission of a feasibility study, etc. A milestone isn't necessarily anything the client can use directly, but as the name suggests, it's usually a fairly potent way of measuring progress against time or distance.

A deliverable, on the other hand — while certainly a mileston — is a usable, albeit incomplete version of an application. Each deliverable meets a particular, growing subset of the project specifications.

Deliverables allow the client to incrementally test functionality, and provide both the client and developer with a real-world assessment of both specification and implementation. Generally, the earlier bugs and design flaws are detected, the less time and money required to identify and correct 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

Upon completion of a free consultation, we provide to the client a rough measure of time-to-completion. Once the design phase is complete, more information will be available to assist recalibration of that estimate. Software estimation is notoriously difficult, but we know time is critical to everyone — personally, professionally, and corporately — so we work diligently to generate timelines that are as accurate as reasonably possible.

As you may have experienced, though, stuff happens. Especially in software: Specification-changes, integration hassles, non-existent documentation, faulty or unreliable client-infrastructure, technological incompatibilities, development environment changes, bugs in third-party components, OS updates that break what used to work, dependencies on external working groups and projects, and a slew of other calamities that cannot be accurately anticipated during design emerge whenever developing almost any significant piece of software.

As these obstacles appear, we handle them. We adjust the scope and schedule of our intermittent deliverables so we can still make the project completion date. We add engineers to the team. We work nights, weekends, and holidays. We consult specialists. We do what we have to in order to fulfill the contract. Whenever any problem increases project-cost or threatens to cause us to miss the completion date, we notify the client immediately and present options to deal with the issue.

Still, pinpointing a completion date can sometimes seem more witchcraft than science. So while we can't promise there will be no delays, we can say we will remain highly communicative throughout the entire process and take every available action to deliver quality work in a timely manner.

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.

Generally, the later in development that changes are requested, the more they cost.

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 his assigned project manager. We provide a template for this.

  2. The 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


Unfortunately, most first-time clients believe that because they are paying us to write code, they own the resulting program. As many traits as the software industry shares with the construction industry, ownership is definitely not among them. Code is intellectual property, and as such, is 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 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 an unlimited number of systems, 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 as source code evolves.

    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 exclusively benefits.

Blade Technologies retains ownership of all 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 his company, we are happy to negotiate that provision. The cost depends primarily on our estimation of the code's 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

We understand that companies need to protect proprietary algorithms, internally-derived formulas, trade secrets, partnership information, employee records, and user data. Thus, we willingly enter into and comply with any non-disclosure agreement we deem remotely reasonable. Further, we never share non-public client information unless granted permission to do so.

However, we may use, as promotional tools, general descriptions and non-exclusive screenshots of the products we build for your company. (We have to have a way to build some sort of a portfolio.) Still, we review every word and image to ensure that no NDAs are violated: We'd want the same 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 entirely: Many non-competes are so laughably broad and 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/or time-limited, we're happy to comply. However, if accepting a job threatens to hamstring us from generating future revenue streams, we will respectfully decline.

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 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, and intermittent errors are often caused by external software and hardware.

  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 significantly different than 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 loss, corruption, or other damage 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 quarter-hour 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. 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. Guaranteed response time is one hour. Support is provided 24/365, including holidays. For situations involving mission-critical software, however, it provides peace-of-mind and can pay for itself with a single incident.
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-Materials Contracts

    We bill monthly, 2/15 net 30 or semi-monthly, 3/10 net 15.

  • Fixed-Price Contracts

    20% down, 50% distributed at milestones, balance — including any overages due to specification changes — upon final delivery.

  • Capped-Budget Contracts

    20% down, 50% distributed at milestones, balance upon final delivery.

Beyond these terms — and under the right circumstances — we will consider profit-sharing, stock options, and less-traditional arrangements in lieu of part or all of our fee.

If a client prefers different terms, we will listen. We strive to make it as painless as reasonably possible to work with us.

[Back to Top]