Why we prefer Straightforward Billing, and you should too
Written by
Dr Alastair Weakley
Published on 16 November 2017
About the author
Alastair co-founded the Interaction Consortium in 2009 and serves as one of the studio's Principal Developers. He has a degree in Design and Technology and after a first career as a product designer for over a decade, he returned to study for a Masters' degree in Information Technology and subsequently completed a PhD ("Internet-based Support for Creative Collaboration", 2007) in Computing Science.
Alastair has collaborated with artists on exhibited interactive artworks as well as publishing in the disciplines of HCI, Information Systems, Information Visualisation and Presence.
Our preferred approach to charging for software development is to charge based on the time we spend. We sell our time in blocks of hours and carefully spend that time working with you to establish, feature by feature, what you actually need to include in your site.
We call this charging style “straightforward billing”.
When we just charge this way, we can all concentrate on delivering the best product possible: the one that meets your true needs within the available budget.
This approach is best for everyone because:
- It’s fair. You only pay for what you need and we get paid for the work we do.
- It’s efficient. We deliver in small chunks, so there’s less risk we’ll take a direction you didn’t intend.
- It’s rewarding. We get a chance to work together with our clients and propose creative solutions.
- It’s low stress. We don’t have to work under the shadow of a budget or scope conflict later in the project.
- It’s low commitment for you. If you’re not happy with the way things are going, you just don’t buy any more of our time.
Straightforward billing also allows us to take steps during the project that save you money and save everyone problems.
Launching the Project Early
This one might sound scary, but it’s better to launch a simple version of a project as early as possible.
This version will have minimal features, but it will let you test the site in the real world, and allows you to build on it, bit by bit. It’s the best way to make sure every feature you add is worth investing in.
This scenario means you won’t spend your whole budget in the first go. Even though our invoice will be smaller, we’re actually happier this way. There’s a higher chance of the end product succeeding if it’s based on real-world testing. And if the product is successful, you’ll probably want to work with us again.
Setting a budget
Just because we like to work without a fixed price or scope, that doesn’t mean you can’t set a budget, or that costs will spiral out of control. Our clients almost always set a maximum budget, and we do our best to deliver as much as we can within that budget.
There are nearly always ways to deliver satisfying results for lower cost by focusing on your core needs and minimising complexity, and we’re really good at coming up with those. From the outset, we’ll guide you towards these sorts of solutions so you get the essentials within the limit you set.
Trust
Working this way requires that you trust us, which we know can be hard when you’re working with new developers. You have one chance and one budget to get your project right, and you don’t want to risk working with folks who hire cheap, slow developers to drive up the number of hours you’re paying for.
We won’t do that. We take integrity extremely seriously. Maybe it’s our background as academics, or maybe it’s just that one should take integrity seriously.
We’re not in the business of building websites so we can get rich and buy super yachts. The most important thing for us is to give our clients the best product we can, even if it can be built without spending all the budget.
We believe very strongly in doing the right thing, doing things the right way, and above all, in learning and improving our performance.
Simply put, we’re passionate about creating valuable code and products that delight people. Straightforward billing helps us to that end.
This post is part of a series about Agile Development and how we use agile approaches at the IC. Get updates to this series and more new ideas by signing up to our mailing list.