Time and Materials Software Development: Cost Control

How Time and Materials Software Development Actually Works and What the Client Pays For

The mechanic fits in one sentence: the client pays an agreed hourly rate for the time the team actually spends on the project. Rates usually differ by role, so a senior backend engineer, a QA specialist and a business analyst are billed at different levels. Time is recorded against specific tasks and reported on an agreed cadence. There is no single fixed total agreed up front, because the total depends on how much work the project turns out to need. That is the entire arithmetic, and the rest of this section is about why the model exists at all.

Time and materials exists because most serious software work has a moving scope. A SaaS product changes direction after the first cohort of paying users. A CRM rollout uncovers three departments with workflows nobody documented. An integration project meets a partner API that behaves differently from its specification. In all three cases, a scope frozen in month one would be wrong by month three. Hourly billing lets the plan follow the business instead of forcing the business to follow a plan written before anyone had the facts.

That flexibility only works when someone owns the backlog. A backlog is simply the ordered list of everything the team could build, with the most valuable items at the top. Under time and materials the client keeps real control over that order: what moves up, what moves down, what gets dropped. Prioritization is the client's main cost lever in this model, and it is far more powerful than negotiating the rate.

The two models also place the risk of a wrong estimate in different places. Under Fixed Price the vendor carries it, which is why a Fixed Price quote always contains a contingency buffer you do not see and cannot audit. Under time and materials the client carries it, which is why the risk is visible in the hour count. Visible risk feels uncomfortable, and that discomfort is the reason this article exists. We return to the full comparison later, because the honest version is more interesting than the usual one.

Now the misconception worth killing early: time and materials does not mean an unlimited budget. Mature hourly engagements run with spending caps per iteration or per phase, agreed thresholds at which the team must stop and ask, and a rolling forecast of what the next period will cost. Those instruments are covered in detail in the governance section below. An engagement without them is not a pricing model, it is an open tab.

It is a common model among development firms. ScienceSoft states on its pricing page that more than 90% of its own development projects are priced under time and materials. That figure describes one vendor's portfolio, not the software market as a whole, and it should be read that way. It signals that suppliers delivering complex, long-running work tend to default to hourly billing, and it says nothing about what share of global IT spend runs on the model. The pattern holds across sectors: a discovery-heavy engagement such as real estate website development in the USA is billed hourly for exactly the same reason.

Why One Invoice Cannot Tell You If a Task Should Take 10, 20 or 40 Hours

Suppose you receive a line item reading "customer export to the accounting system - 26 h". You have no way to judge that number from the line alone. The reason is not that vendors hide information. The reason is that the cost of a software task is set by the environment it lands in, and the environment is invisible from outside the codebase. The same feature, described in the same words, can honestly cost 6 hours on one system and 40 on another.

These are the variables that legitimately move the number, and every one of them is real:

• State of the existing codebase. Clean, tested code accepts a change quickly. Code that has grown for eight years without refactoring resists it.
• Legacy components. An old module that nobody on the current team wrote has to be understood before it can be touched safely.
• Documentation quality. When behaviour is undocumented, someone has to reconstruct it by reading code and running experiments.
• Integrations. Every system on the other side of a connection has its own data model, error behaviour and failure modes.
• Third-party APIs. Rate limits, sandboxes that differ from production, authentication schemes and undocumented edge cases all consume real time.
• Debugging. Finding the cause of a defect is research work, and research does not follow a predictable schedule.
• Testing. A payment flow needs a different depth of verification than an internal admin screen.
• Infrastructure dependencies. Pipelines, environments, access rights and data migrations sit between finished code and a working feature.
• Constraints that could not be known before work started. A security requirement or a data volume that surfaces once someone opens the system.
• Required research. Choosing between two technical approaches takes time even when writing the code afterwards is fast.

The buyer-side conclusion follows directly: there is no industry table of normal hours per task, and any vendor who offers one is selling you a fiction. The unit of comparison is not the feature name, it is the feature in a specific system, with specific data and specific constraints. Benchmarking your invoice against what a colleague paid for a "similar" integration produces noise rather than insight.

The difficulty is not anecdotal, it is documented. Jorgensen and Shepperd catalogued 304 software cost estimation papers published across 76 journals in their systematic review of software development cost estimation studies. Estimating software effort is its own research field with decades of literature behind it, precisely because no simple hour norm exists.

An Estimate Is a Forecast, Not a Guaranteed Number of Hours

This is the single most useful correction a buyer can make to their own mental model. A 20 hour estimate does not mean the objectively correct duration of that task is 20 hours. It means an experienced person, using the information available before the work began, expected roughly 20 hours. The estimate is a prediction made under uncertainty, at the moment when the least was known about the task.

Research on expert estimation supports the caution. Magne Jorgensen's review of studies on expert estimation of software development effort documents substantial uncertainty and inconsistency in how software effort is estimated, including cases where the same task presented to different estimators produces materially different numbers. This is a property of the work, not a failure of any individual team.

The practical consequence changes the conversation. Stop treating the estimate as evidence of how long the task was obliged to take, and start treating it as a baseline for variance analysis. When actual differs from estimate, that difference is a signal to investigate, not a verdict. The useful question is what the team met during the work that the estimate did not anticipate, and whether it was knowable in advance. A vendor who answers that consistently is giving you something more valuable than an estimate that happens to be right.

What Makes Hourly Work Transparent: From Task and Estimate to Result and Actual Hours

Transparency in time and materials software development is not a reporting format. It is a set of artifacts that exist at three moments - before the work, during the work and after the work - and stay connected to each other. When all three exist, an hour count becomes interpretable, because you can see what it was spent on, what it produced and why it differs from the plan. When any one of them is missing, the chain breaks and the number floats free of context. This is the spine of everything that follows in this article.

Before work starts, four things should exist for any task of meaningful size:

• Task description. What is being built or changed, in language the business can read.
• Business purpose. Why it is worth doing. This is what lets you deprioritize it later without a negotiation.
• Estimate or range. A range is usually more honest than a single figure, because it exposes how much uncertainty the team sees.
• Acceptance criteria. The conditions under which the task counts as done. Acceptance criteria written before the work prevent the most expensive argument in software delivery, which is the one about whether something is finished.
• Assignee and role. Which role does the work, since the role determines the rate.

During the work, the visible state matters more than the volume of reporting:

• Status. Where the task stands right now, in the tracker, not in an email.
• Actual burn. Hours booked so far against the estimate. Burn is simply the rate at which budget is being consumed.
• Blockers. What is stopping progress, including the things the client needs to unblock.
• Scope changes. Anything added to the task after it started, recorded as an addition rather than folded silently into the original line.
• A proactive warning on material deviation. The team tells you before the estimate is blown, not after.

After the work, the closing artifacts turn hours into something you can evaluate:

• Result. What now exists that did not exist before.
• Actual hours. Booked against the task, not against a generic bucket.
• Evidence. A demo, a release, a pull request, a test result, a design artifact, updated documentation.
• Explanation of material variance. In business language, for any task that moved significantly away from its estimate.

Read end to end, that is the model this article keeps returning to: Task -> Estimate -> Work -> Evidence -> Result -> Actual -> Variance. Every governance instrument described below keeps one link in that chain intact. A useful exercise is to take your last invoice and walk the chain backwards from a single line item. Wherever you cannot reach the next link, you have found the part of the process that needs fixing.

Professional practice frameworks make a related distinction. The Project Management Institute's guidance on management of third-party software development suppliers treats supplier monitoring and deliverable acceptance as separate governance elements. Monitoring is knowing what is happening while it happens. Acceptance is confirming that what was delivered meets the agreed criteria. Many buyer-vendor relationships collapse these into a single monthly ritual, and then discover that neither is actually being done.

«Mouse movements, screenshots, and the number of commits say nothing by themselves about the value of a developer’s work. Six hours spent finding the cause of a production bug may result in changing just three lines, while a day spent studying legacy code may prevent a critical process from breaking. At the same time, twenty commits and high activity may turn out to be work that is later rolled back. “Activity is not output, and output is not a business outcome.” That is why a B2B client should control not the developer’s actions, but the chain: task, estimate, completed work, technical confirmation, result, and actual time spent. Developer productivity cannot be objectively assessed by a single metric.»

Andrew Popow

CTO

How to Audit an Invoice for 20-40 Hours: A Step-by-Step Algorithm

This is the practical instrument most readers came for: a repeatable procedure you can run against one specific invoice, this week, with the documents you already have. It takes about thirty minutes for a typical monthly statement. Run it the same way every time, because consistency is what turns it from an argument into a process. The goal is a conversation with a structure, and the structure is what keeps the conversation productive.

Step 1 - Compare estimate and actual. Pull the original estimate for each significant line and put it next to the billed time. Say the estimate was a range of 16-24 hours and the actual is 31. The question to ask is not "why 31?", because that invites a defence of the whole task. The question is "what added the extra 7 to 15 hours?" That version asks about a specific delta, and a delta has causes that can be named. Do this for the three or four largest lines rather than for everything; the small items rarely carry the variance, and chasing them costs more attention than it returns.

Step 2 - Check the decomposition. A line reading "CRM integration - 38 h" is not auditable by anyone, including the vendor. The same work decomposed is immediately legible: API research 6 h, authentication 4 h, data mapping 9 h, implementation 12 h, tests 4 h, deployment 3 h. Now you can see where the weight sits, and you can ask a narrow question about the heaviest sub-item. Decomposition is also a quality signal in its own right, because a team that cannot break a task into parts before starting it usually has not thought the task through. If your invoices arrive undecomposed, fix that before anything else on this list.

Step 3 - Separate scope change from overrun. These are different events with different owners, and conflating them is the most common source of unnecessary conflict. An overrun means the agreed work cost more than expected. A scope change means additional work appeared during the task, often requested by someone on the client side in a chat thread that never reached the tracker. Ask which parts of the billed time correspond to things that were not in the original description. In our experience a significant share of disputed hours turns out to be scope that the client asked for and then forgot, which is a governance gap rather than a billing problem.

Step 4 - Match time against outcome. For each significant line, ask what exists now that did not exist before, and what artifact demonstrates it. The evidence set is well known: completed tasks in the tracker, pull requests, code review records, test results, a release, a demo, design artifacts, updated documentation. Any one of these is worth more than a timesheet narrative. State the limit plainly: a commit is a supporting signal, not a unit of productivity. Ten commits can be one hour of work and one commit can be three days of it. What you are checking is that billed time resolves into something inspectable, not that it resolves into a particular quantity of anything.

Step 5 - Request an explanation of material variance. Set a threshold in advance - many mid-market engagements use 25% or 30% over the upper end of the range - and ask for an explanation on anything that crosses it. The explanation should be two or three sentences in plain business language: what was met, when it was discovered, what was decided, what it cost. A vendor who answers with "software is unpredictable" is telling you they did not track the cause.

Two closing notes on how to use this. First, the algorithm is a conversation structure, not an interrogation script; run it with the vendor rather than at them, and say that you run it every month so nobody is surprised. Second, it works best when it stops finding things. The purpose is to establish a standard of documentation that makes monthly findings unnecessary. Teams adapt to the questions they get asked regularly, and that adaptation is the actual return on the thirty minutes. The same evidence-first standard applies to any specialist work you buy by the hour, from a security review to an SEO site audit: ask for the findings, not for the hours.

When an Hours Overrun Is Objectively Justified

A section like this belongs in any honest treatment of the subject, because an article that lists only warning signs trains the reader to see a problem in every variance. Most overruns in competent teams have a specific, nameable technical cause, and the business consequence of treating them all as suspicious is that the team stops reporting them early. The test that matters is not whether the overrun happened. It is whether it was explained, and when.

These are the drivers we meet most often in mid-market work:

• Undocumented legacy code. Behaviour has to be reconstructed by reading and experiment before it can be changed safely.
• Undocumented API behaviour. The partner system does something its specification does not mention, and the workaround has to be designed and tested.
• A hidden dependency. Changing one module turns out to affect another that nobody connected to it.
• Data migration problems. Real production data contains states the schema says are impossible.
• Version incompatibility. A library, runtime or platform upgrade is required before the actual task can proceed.
• Security or reliability issues surfacing mid-task. An access control gap or a race condition found on the way to something else, which is cheaper to fix now than later.
• Changed scope. The requirement grew during the work, whoever initiated it.
• A need for extra testing. The change touches a business-critical path and deserves more verification than originally planned.
• An initial assumption that turned out to be wrong. The approach chosen at estimation time does not survive contact with the system, and a different one is needed.

Two short scenarios make the category concrete. A mid-sized distributor asks for a two-way sync between its CRM and its order system, estimated at 20 hours. The CRM's API returns a success code for updates it silently discards when a custom field is empty, which is documented nowhere. Detecting that behaviour, proving it and building a verification step around it costs 11 additional hours. Alternatively, a manufacturer modernizing a 2013 internal portal asks for a new reporting screen. The reporting query turns out to depend on a nightly job that another department relies on for invoicing, so the change has to be coordinated and tested against that job. Neither team estimated badly. Both met a fact that was not visible before work began.

The distinction that separates these from a governance failure is timing and disclosure. In both scenarios above, the right behaviour is to raise the issue on the day it is found, state the expected additional cost, and ask the client whether to proceed, simplify or stop. An overrun disclosed at the moment of discovery is a project event the business can act on. The same overrun disclosed thirty days later in an invoice is a loss the business can only absorb. That difference, not the hours themselves, is what separates a mature partner from a problematic one.

Nine Signs Something Is Genuinely Wrong with Hourly Development

The previous section audited a single invoice. This one diagnoses the delivery process behind it, which is a different exercise with a different time horizon. Process problems do not show up in one document; they show up as patterns across several months. Read the list below against your last quarter rather than your last statement. These are signals about how work is organised, and each of them is fixable if it is named early.

1. No estimate exists even for substantial tasks. Without a baseline there is no variance, and without variance there is nothing to discuss. A team that will not estimate is a team that cannot be held to anything.
2. Large tasks are never decomposed. Items sized in tens of hours arrive as single lines. This hides both cost and risk, and it usually means planning happens during the work rather than before it.
3. A material overrun surfaces only in the invoice. The single most damaging pattern on this list, because it removes the client's ability to make a decision while a decision would still matter.
4. Timesheets read "development - 8 h". Generic entries that could describe any work on any project. The fix is cheap and the resistance to it is informative.
5. The team does not explain variance causes. Overruns are acknowledged but never attributed. Nobody learns anything, and the same cause recurs next quarter.
6. There is no link between time and specific backlog items. Hours are booked to the project rather than to tasks, so spend cannot be connected to priorities.
7. The client never sees the actual output of the work. No demos, no access to a running environment, no releases you can look at. Progress exists only as description.
8. Rework is billed routinely without a root-cause discussion. Some rework is normal and expected. Regular rework with no analysis of why it keeps happening means the same defect in the process is being paid for repeatedly.
9. There is no clear budget forecast or remaining estimate. The team can say what has been spent but not what finishing will cost. Reporting is entirely backward-looking.

How to read your own score. One flag is a conversation to have at the next review, and most engagements have one at some point. Two flags that appear together usually share a root cause, and naming it is often enough. Three or more is a governance problem that will not resolve on its own, because each missing element removes the information needed to fix the others. At that point the useful move is to reset the working agreement - decomposition rules, reporting format, escalation thresholds - rather than to escalate the tone of the monthly email.

How to Control a Time and Materials Budget Without Micromanaging the Team

The goal is visibility into spend, and visibility is not the same thing as supervision. Surveillance produces defensive behaviour, slows delivery and tells you nothing about whether the money is buying the right things. Good governance works at the level of the engagement rather than the individual: it sets the cadence at which information arrives, the thresholds at which the business gets a decision, and the limits beyond which work does not continue without approval. Six instruments cover nearly all of it, and none of them require anyone to watch a developer work. They transfer directly to any other retainer you run on hours, including digital marketing, where monthly volume varies in the same way.

Estimate vs Actual as a Trend

A single task that went 60% over its estimate tells you very little, and a team that never overruns is probably padding. What tells you a great deal is the distribution across thirty or fifty tasks: whether overruns and underruns roughly balance, whether the spread is narrowing as the team learns your system, and whether particular categories of work are systematically underestimated. Track the trend monthly as a health indicator rather than a scorecard. A stable, mildly conservative estimation record is one of the strongest signals of a team that understands what it is working on.

Weekly or Biweekly Budget Review

The monthly invoice is the worst possible moment to learn about spend, because by then every decision it might have informed has already been made. A short review every week or two - twenty minutes, hours booked against plan, what changed, what is coming - keeps the number small enough to act on. Put the cadence in the working agreement rather than relying on goodwill, because the weeks when the review matters most are the weeks when everyone is too busy for it. The review is also where scope changes get recorded before anyone forgets who asked for them.

Remaining Estimate and Forecast

Actual hours look backwards. What a business needs for planning is a view forwards: the remaining estimate, meaning the team's current expectation of what is still required to finish the agreed scope, and a forecast of the next period's cost. Both should be refreshed as the work proceeds, because a remaining estimate produced at the start and never updated is just the original plan wearing a different name. Ask for the forecast in the same format every period so you can watch it move. A forecast that keeps rising quietly is information; a forecast that only exists after you request it is a red flag from the previous section.

Budget Threshold Alerts

Agree in advance on a deviation at which the team must stop and notify you - a percentage over the task estimate, or an absolute amount on an iteration budget. When the threshold is crossed, the team's obligation is to report it and request a decision. This single rule changes the shape of the whole engagement, because it moves escalation from something the client has to discover into something the vendor owes. Write it into the agreement with a number in it. "The team will keep us informed" is not a threshold.

Capped Time and Materials and Not-to-Exceed

Capped time and materials keeps hourly billing but adds a ceiling: the client pays for actual hours up to an agreed maximum for an iteration, a phase or a defined task scope, and work does not continue past the cap without a new decision. A not-to-exceed clause does the same job in contract language. The structure gives the business the budget certainty it wants from Fixed Price while keeping the flexibility and visibility of hourly work, and it is a normal commercial arrangement rather than an unusual concession. ScienceSoft's pricing page lists capped time and materials among its standard models, which is a useful reference if you meet resistance to the idea. One trade-off to understand: a cap set too low for the scope converts into either reduced scope or a renegotiation, so it works best on well-bounded iterations.

Stop and Continue Checkpoints

A checkpoint is a scheduled moment - the end of an iteration, a milestone, a fixed budget consumption point - at which the work does not automatically continue. There the client can continue as planned, reprioritize the backlog, cut scope, run a short discovery to reduce uncertainty, change the technical approach, or stop the work entirely. The value is in owning the option rather than in exercising it, because an engagement with real stop points is one where the client's leverage does not depend on the vendor's goodwill.

Taken together these six instruments do one thing: they move information to the client early enough to be useful, without anyone monitoring a screen. That is the whole of budget control in time and materials software development. The engagements that go wrong are rarely the ones where the team was slow. They are the ones where nobody set a threshold, nobody scheduled a review, and the first real conversation about money happened after the money was gone.

«If a business can see in advance that a task is exceeding its estimate, it can still influence the cost: simplify the solution, reallocate the budget, postpone part of the work, or stop the task. That is why we see transparency not as reporting after the fact, but as a decision-making tool during development. The Scrum Guide describes this as “transparency, inspection, adaptation” and emphasizes: “Inspection without transparency is misleading and wasteful.” A monthly invoice shows what has already happened, while transparency makes it possible to change what happens next.»

Andrew Popow

CTO

Which Metrics Help and Which Create a False Sense of Control

Every metric a business tracks is also an instruction to the team about what to optimize, which is why the wrong ones are worse than none at all. The metrics below split into two groups: those that describe delivery and can support a decision, and those that describe activity and cannot. The second group is not forbidden. It is simply incapable of carrying the weight that buyers often place on it, and the damage appears when an activity number becomes the basis for an evaluation.

The left column shares one property: each item describes the flow of work or its outcome, so improving the number requires improving the delivery. Cycle time falls when handoffs and blockers are removed. Rework falls when requirements and review get better. Defects fall when testing is adequate. These metrics resist gaming because the cheapest way to move them is to do the work better.

The right column shares the opposite property: each item measures observable activity, and every one of them can be increased without producing anything. Commits can be split. Tickets can be sliced. Keyboard activity can be generated. This is the core of the argument in the SPACE framework: developer productivity is multidimensional, no single metric represents it, and optimizing for one dimension distorts behaviour in the others. A team measured on commit count will produce commits. Whether it produces working software is a separate question that the metric cannot answer.

A practical way to choose: for each number you plan to track, ask what decision you would make if it moved by 30%. If the answer is concrete - reprioritize, add a person, investigate a bottleneck, change the approach - the metric earns its place. If the answer is "I would ask the team about it", you have a conversation starter rather than a control.

Do You Need a Time Tracker with Screenshots

The direct answer: a time tracker with screenshots can serve as a supporting tool in specific working models, and it must not be the basis for evaluating knowledge work. Where it genuinely helps is in short, transactional engagements with unfamiliar individual contractors, or where an existing compliance process requires an activity record. Even there it verifies presence rather than value, and presence was never the thing in doubt.

This question dominates the German-language search results around Projektzeiterfassung and Abrechnung nach Aufwand, so it deserves a straight answer rather than avoidance. Structured time recording against tasks is genuinely valuable: it is what lets you connect hours to backlog items, compare estimate with actual, and build a forecast. That is a different thing from screen capture. Recording time against a task produces information a business can act on. Capturing a screenshot every ten minutes produces an archive nobody reviews, and it adds a cost that appears in your invoice as the time it takes to manage it.

The stronger position for a buyer is to require the artifacts instead. Ask for decomposed tasks, estimates, tracker access, evidence of results and variance explanations. A team that provides those is legible whether or not anyone screenshots anything. A team that provides screenshots and nothing else has given you a great deal of data and no information.

Does Fixed Price Protect You from Overpaying Better Than Time and Materials

The direct answer is no, not necessarily, and the reasoning matters more than the verdict. Fixed Price feels safer because it converts an open number into a closed one, and a closed number is easier to approve internally. What it does not do is remove the underlying uncertainty about how much work the software actually requires. That uncertainty has to go somewhere, and under Fixed Price it goes into places that are harder for a buyer to inspect than an hour count.

Under time and materials the risk of a wrong estimate sits on the surface. You see it as hours, in the period they were spent, attached to the task that caused them. It is uncomfortable and it is visible, and visible risk can be managed with the instruments described earlier in this article. Under Fixed Price the same risk is relocated into a vendor contingency buffer priced into the total, hard scope boundaries that turn every clarification into a negotiation, a change request process with its own commercial dynamics, simplified technical solutions chosen to protect the vendor's margin, and in the worst cases quality compromises in the parts of the system the client is least equipped to inspect.

Notice the last row of the table, because it is the point of the whole comparison. Both models fail, and they fail in different ways, and in both cases the failure is a governance failure rather than a pricing one. The pricing model decides where you will have to pay attention. It does not decide whether you have to.

So the practical conclusion is not "choose this one". It is that a business which has not defined acceptance criteria, reporting cadence, escalation thresholds and a decision process will overpay under either model. A business that has defined them can run either model successfully and will usually prefer time and materials for evolving work and Fixed Price for well-bounded work, which is exactly the subject of the next section.

When Time and Materials Software Development Fits a Mid-Sized Business

The fit question has a reliable answer, and it does not depend on company size or budget. It depends on how much is unknown at the start and how much is expected to change during the work. Where uncertainty is high, hourly billing is the honest model and Fixed Price becomes an expensive way to pretend otherwise. Where the work is genuinely well defined and stable, a fixed total is simpler for everyone and there is no reason to avoid it.

Time and materials tends to be the right choice in these situations:

• SaaS product development. Direction changes with market feedback, and the roadmap you commit to in January is not the one you should be building in June.
• Evolving an existing CRM or ERP. The system already has users, data and dependencies, and the real scope reveals itself as you work.
• Complex integrations. The behaviour of the systems on the other side is only partly knowable in advance.
• Legacy modernization. Uncertainty is the defining property of the work, since the codebase is the specification.
• AI functionality. Results depend on data quality and on experimentation that cannot be scheduled precisely up front.
• An evolving backlog. Priorities are reassessed every few weeks against business results.
• Long-term development of a corporate platform. The engagement outlasts any scope document that could be written for it.
• Support and continuous improvement. Volume varies month to month by nature.

The weaker fit is a well-bounded, stable scope where both sides can describe the finished thing in detail before starting: a marketing site, a defined migration, a contained module with a clear specification and no dependency on discovery. In those cases Fixed Price or a hybrid arrangement - Fixed Price for the defined core, hourly for the parts that depend on findings - is often more convenient for everyone involved. A brochure site of that kind is routine work for a web design agency in the USA and can be quoted as a fixed total with confidence.

The decision rule we give clients has three questions. How stable is the scope over the expected duration of the work? How much is genuinely unknown at the start, particularly about systems and data you do not control? How long is the engagement, since longer engagements accumulate change regardless of how firm the initial plan looked? High stability, low unknowns and a short horizon point to Fixed Price. Any two of the opposite point to time and materials with proper governance, and a capped arrangement on each iteration will usually satisfy whatever budget certainty the business needs.

Checklist: What to Agree with an IT Vendor Before Starting Hourly Development

Everything in this article is easier to establish before the engagement starts than after the first disputed invoice. The list below is written to be taken into a vendor call and worked through point by point; a competent partner will have answers to most of it already and will not treat the questions as unusual. Expect the conversation to take an hour. That hour is the cheapest governance you will ever buy, and the way a vendor responds to it tells you as much as the answers themselves.

Commercial terms

• Hourly rates by role, with the roles named.
• Who is allowed to bill hours to the project, and who approves adding a person.
• What counts as billable work, stated explicitly.
• How QA, code review and meetings are counted.
• Rework rules: what is billable, what is not, and who decides.

Estimation and scope

• Estimation rules: which tasks get estimated and at what point.
• The format of an estimate - a single figure or a range, and what the range means.
• Backlog ownership and who sets priority order.
• Acceptance criteria: who writes them and when they must exist.

Reporting and transparency

• Time reporting format, including the level of detail per entry.
• Reporting cadence, with dates rather than intentions.
• Access to the project tracker for your team, read access at minimum.
• Access to work outputs: environments, releases, pull requests, documentation.

Budget governance

• When the team must report a variance, expressed as a number.
• The budget threshold that triggers a notification and a client decision.
• A budget cap per iteration or phase, if you want one.
• Remaining estimate and forecast, and how often they are refreshed.
• A regular plan-versus-actual review, scheduled in advance.

Two notes on using the checklist. You do not need every item on a small engagement, and insisting on all eighteen for a three-week piece of work will cost more attention than it saves. Pick the items that match the size and duration of what you are starting, and add the rest as the engagement grows. The second note matters more: agree these things in writing, in whatever document governs the relationship. Verbal understanding about escalation thresholds survives exactly until the first month when escalating is inconvenient. Scale matters less here than you would expect: a short engagement for beauty salons SEO in the USA deserves the same written thresholds as a year-long platform build.

How a Mature IT Partner Builds Transparency into Delivery and Budget

The problem with time and materials is usually not the hourly model. It is the absence of process around it. The model itself is neutral: it bills time, and whether that time is legible depends entirely on the artifacts the delivery team produces while spending it. Every instrument in this article - decomposition, estimates, thresholds, forecasts, evidence - is something the vendor side owns and the client side should be able to rely on without asking.

At Webdelo we build B2B platforms, ERP and CRM systems, FinTech tools, integrations and high-load services for mid-sized companies in the US, Germany and Eastern Europe, and we have worked this way since 2006. On hourly engagements the process side of the work is explicit. We decompose tasks before estimating them, so the estimate has a structure you can inspect rather than a single number you have to accept. We estimate in ranges that reflect real uncertainty. We keep the backlog visible to the client and expect the client to own its priority order, because prioritization is where the money is actually controlled. We escalate variance when we find it, not when we invoice it. We provide a forecast alongside the actuals, so the conversation is about the next period rather than only the last one. Every hour connects to a task, and every task connects to something you can look at: a release, an environment, a pull request, a test result, a document. The same process applies whether the engagement is a platform build or straightforward web development in the USA.

The part that matters most to a mid-sized business sits above the delivery mechanics. Scope is a budget decision, and most of the savings available on a software project come from deciding what not to build rather than from negotiating the rate on what you do. We expect to be part of that conversation - which items carry real business value, which can wait a quarter, which can be met by a simpler solution at a fraction of the cost, and where a short discovery will remove enough uncertainty to make the rest of the work predictable.

That is the role we think an IT partner should play for a mid-sized business: helping manage delivery, risk and IT investment, with the hourly model as the billing mechanism rather than the relationship. Transparency is what makes the arrangement work in both directions. It gives the client the information to make decisions during delivery, and it gives the team the freedom to solve problems properly without being measured by activity.

Frequently Asked Questions

Can you actually verify whether a developer really worked 20 hours?

Not directly, and no monitoring tool changes that. What you can verify is the chain around those hours: the task they were booked to, the estimate they are compared against, the evidence produced, the result delivered and the explanation of any material variance. If that chain is complete, the hour count is interpretable.

How many hours should a typical development task take?

There is no industry norm, because the same feature costs different amounts on different systems. The cost is driven by the state of the codebase, legacy components, documentation quality, integrations, testing depth and infrastructure dependencies. Comparing your invoice to what another company paid for a similarly named task produces noise rather than insight.

What should I do if the actual significantly exceeds the estimate?

Ask what added the difference rather than why the total is what it is, since a delta has nameable causes. Then separate scope that appeared during the work from an estimate that was wrong, because those are different events with different owners. Finally, agree a threshold at which future variances must be reported before the work continues.

Should an IT vendor provide a detailed timesheet?

Yes, at the level of tasks rather than minutes. Entries should connect to specific backlog items so that time can be compared with estimates and with delivered results. Generic lines such as "development - 8 h" are not usable for governance and should be treated as a process gap to fix.

Is it normal to bill meetings, QA and code review?

Yes. Requirements clarification, testing and code review are part of producing working software, and removing them makes a project riskier rather than cheaper. What matters is that the rules are agreed before the engagement starts and that this time is recorded transparently.

Can you manage developers without screenshots?

Yes, and it works better. Structured time recording against tasks, decomposed estimates, tracker access, delivery evidence and variance explanations give a business everything it needs to make decisions. Screen capture measures presence, which is rarely the thing actually in question.

What is capped Time and Materials?

It is hourly billing with a ceiling. The client pays for actual hours up to an agreed maximum for an iteration, a phase or a defined scope, and work does not continue past that cap without a new decision. It combines the flexibility and visibility of hourly work with the budget certainty most businesses want from Fixed Price.

Which is better for a mid-sized business: Fixed Price or Time and Materials?

It depends on how stable the scope is and how much is unknown at the start. Well-bounded, predictable work suits Fixed Price; evolving products, integrations, legacy modernization and long-term development suit time and materials with a cap per iteration. Neither model substitutes for governance.

Conclusion: Audit the Chain, Not the Hour

The central idea of this guide compresses into one line: you cannot audit an hour, and you can audit a chain. Time and materials software development becomes controllable the moment a business stops arguing about individual numbers and starts requiring the artifacts that make numbers meaningful - the task, the estimate, the work, the evidence, the result, the actual and the reason for the variance. Every governance instrument described above exists to keep one link in that chain intact.

Three things are worth carrying away. Build traceability before the project starts, because retrofitting it after a disputed invoice is slower and more expensive. Detect variance while you can still act on it, since an overrun reported on day two is a decision and the same overrun reported in a monthly invoice is a loss. And never let a single activity metric stand in for delivery evidence, because a number that can be increased without producing anything will eventually be increased without producing anything.

None of this requires a large process apparatus. It requires decomposed tasks, honest estimates, a short regular review, an agreed escalation threshold and evidence you can look at. Most mid-sized businesses can put that in place in a few weeks, and the return shows up in better decisions rather than in a smaller invoice.

If you are setting up hourly development with an external team, or your current engagement is producing invoices you cannot interpret, talk to us. We are happy to walk through how estimation, reporting and budget control can be organised on your project - the decomposition format, the reporting cadence, the thresholds and the forecast - whether or not the work ends up with Webdelo. It is a practical conversation about your delivery process, and there is usually something useful in it either way.