Bugs Happen

As a means of coming to terms with the realities of development, let’s say it out loud together on three. One… Two… Three!

“Bugs happen!”

There. Now, doesn’t that feel better?

The truth of the matter is that bug fixing is just another part of development. And, believe it or not, fixing a bug found by an end user or administrator is less expensive than our team spending hundreds of hours trying to find and define one (which may or may not even exist).

So instead, here’s what we do:

• We outline expectations to meet the scope of your project.
• Test what we can – knowing that covers 95% or more of typical user interactions.

Why can’t you guarantee your code is bug-free?
To try and define every feature, workflow, and external factor in advance would be darn near impossible to achieve. Let alone fit it into the budget for you and your project. Because of this, wisnet charges for bug fixes.

Bugs happen all over the place with every sized team.
From large corporate entities with 1,000s of developers and testers on payroll, down to our humble but mighty team of a baker’s dozen.

Achieving the best results
We’re always striving to be as transparent as possible and deliver the very best end-product, so if you have questions on how we quote and carry out projects, let us know!

With that out of the way, when we start planning your project we’ll work with your team to outline the following:

• What support will look like for post launch requests and issues that get raised by your initial user base.
• How you’d like to tackle each of those post launch requests along the way.

Here are just a few examples of how we’ve structured that support for other projects. Your plan might look like one of these or something even more customized for your needs!

Option 1: Budget Threshold

In this scenario, we’d set a threshold of a certain number of hours per week or month to work on a prioritized queue set by you. Our team would then tackle each issue in the order you’ve determined, leveraging the hours available each time period.

Option 2: Issue Threshold

Issues would be submitted by you, the client, for our team to review. If estimated billable time is under a specified number of hours, then our team would perform and submit them for review without a need for explicit approval on each issue.

If estimated billable time is at or above that specified number of hours, then an estimate would be shared with you to approve or reject. If approved, development ensues. If rejected, we put in the backlog until you decide to pursue development.

Option 3: Issue by Issue

Issues would be submitted by you and with every one, we would share an estimate with you to approve or reject. If approved, development ensues. If rejected, we put in the backlog until you decide to pursue development.

With any support structure, our team strives to strike the balance between utter transparency and being efficient with your time and money. If you ever need more context about how we work, hit us up and let’s chat!