The quoted number on a software proposal is almost never what you end up paying. I've sat through enough vendor demos to know the pattern: a clean per-user figure on the slide, an implementation fee mentioned in passing, and three line items you don't discover until the second invoice. If you manage subcontractors and schedules for a living, the pricing model matters as much as the feature list, because the model decides whether the tool stays cheap as your business grows or quietly becomes a budget problem the year you land three more jobs.
This is a plain walk through the pricing structures you'll actually run into, what each one rewards and punishes, and the hidden costs that turn a good deal into a bad one. The goal isn't to steer you toward any one product. It's to help you read a quote the way you'd read a bid — knowing where the money is buried.
Per-user pricing: simple until you invite the subs
Per-user (per-seat) pricing charges you for every person who logs in. It's the easiest model to understand and the easiest to underestimate. On paper, $30 a seat for a ten-person office team is $300 a month, no drama.
The trap shows up when the platform's whole value depends on other people using it. A look-ahead schedule is worth far more when your framing sub, your MEP foremen, and the GC's super can all see it and mark up constraints. But if each of those people needs a paid seat, the tool that was supposed to improve coordination now penalizes you for coordinating. I've watched teams keep subs off a platform purely to hold seat count down, which defeats the entire point of buying it.
Before you sign a per-seat deal, ask two questions vendors don't always volunteer. First, are field and subcontractor users the same price as office users, or is there a cheaper "viewer" or "field" tier? Second, can inactive seats be reassigned month to month? A crew that ramps up for a six-week concrete pour shouldn't lock you into twelve months of seats you use for six weeks.
Per-project pricing: friendlier to field adoption
Per-project pricing flips the logic — you pay by active job, and within each job you typically get unlimited users. For a superintendent, this is usually the model that actually fits how a look-ahead is meant to be used: put everyone who touches the schedule on it, subs included, without watching a meter.
The gotcha is the definition of "project." Read that clause carefully. Some vendors count a single building as one project. Others count each phase, each tower, each permit, or even each location as a separate billable project — so your one large job that you think of as one job suddenly bills as four. On a phased multi-family or a campus with several buildings, that distinction can triple your cost. Make the vendor put their project definition in writing and price it against how you break down your work, not how they'd prefer to.
Tiered pricing: watch the one feature you can't live without
Almost everyone offers tiers — call them Basic, Pro, Enterprise or whatever. The tiers aren't the problem. The problem is when a single feature you genuinely need sits one tier above where the price makes sense.
For scheduling tools, the usual "gotcha" features living in higher tiers are trade-flow or sequence linking, historical/baseline comparison, custom reporting or exports, API access, and role-based permissions. If linking your trade flows so a slip in framing automatically flags the electrician is a top-tier feature, then the top tier is your real price — the lower tiers are marketing. Map your must-haves against the tier chart before you talk dollars, and price the tier that actually contains all of them. Starting low and getting forced to upgrade mid-contract is how you lose your negotiating leverage.
Enterprise licensing: unlimited, at a price and a commitment
Enterprise agreements swap the meter for a flat annual fee: unlimited users, unlimited projects, usually with dedicated support, onboarding, and some customization thrown in. If you're a larger GC running dozens of jobs and hundreds of people, the math frequently lands in your favor — and the included training and a real support contact are worth actual money on a rollout.
Two cautions. Enterprise deals almost always carry minimum commitments and annual (not monthly) terms, so they're a poor fit if your headcount swings hard between busy and slow seasons. And "unlimited" is only a bargain if you'll actually use the volume — a mid-size shop can talk itself into an enterprise tier it never grows into. Do the per-user-equivalent math on your realistic user count and compare honestly.
Transaction-based pricing: unpredictable by design
Some platforms charge by usage — per document, per activity, per commitment tracked, per API call. The appeal is that a small operation pays small. The risk is that your cost is now tied to a number you don't fully control and can't cleanly forecast.
Look-ahead and short-interval scheduling are inherently high-activity work: you're revising weekly work plans, logging constraints, updating commitments as they clear. That's exactly the kind of usage that spikes a transaction bill right when a job gets busy — which is precisely when you least want a surprise cost. If you're quoted a transaction model, get the exact definition of a billable transaction in writing, then estimate your monthly volume from a real past job and multiply. If the vendor can't help you model that, treat the ambiguity as a red flag.
Freemium: fine for a pilot, thin for a portfolio
Free tiers are a genuinely good way to test-drive a tool on one job before you commit. A small remodeler running a single project at a time might live in the free tier indefinitely, and that's a legitimate outcome.
Just know what the free tier withholds — it's usually the thing you'll eventually need. Common limits are a hard user cap, a project cap, restricted history, no exports, and no integrations. Use free to answer one question: does my crew actually adopt this in the field? If the foremen open it on their own without being nagged, you've learned the most important thing money can't tell you. If they don't, no paid tier will fix that.
The costs that never make it onto the pricing page
Subscription price is the part everyone compares. The costs below are where deals actually go sideways, and they rarely appear on the slide.
- Implementation and setup. Configuration, importing your existing schedules, and building templates take time. Ask whether it's a fixed fee or hourly, and get the scope in writing. "We'll help you get set up" is not a number.
- Training. Not just the kickoff session — the refresher for the field, and onboarding every new hire and every new sub for the life of the contract. In construction, turnover means training is a recurring cost, not a one-time one.
- Support tier. Find out what "support" includes at your price. Email-only with a two-day response is very different from a phone line during a live pour when the schedule won't sync. Premium support is often a separate line item.
- Integrations. Connecting to your accounting, project management, or document system may be included, may cost a one-time fee, or may bill per connection — and connections need maintenance after setup. If an integration is central to your workflow, price its full lifetime, not just the hookup.
- Data export and offboarding. The question nobody asks in the demo: if you leave in two years, do you get your data out cleanly, and does that cost anything? A vendor that makes leaving painful has leverage over you at every renewal.
How to actually compare quotes
Run the numbers over three years, not one month. Introductory pricing and first-year discounts routinely flip once the deal renews or once you grow into a higher tier, so a five-year total-cost view tells the real story. Build a simple spreadsheet with your projected user count, project count, and job mix for years one through three, then drop each vendor's model into it. The cheapest headline number often loses this comparison badly.
A few rules of thumb from having done this more than once:
- Price the model against your growth, not today's size. The right answer for a two-job shop is often the wrong answer at ten jobs. Ask where the cost cliff is.
- Never let seat cost keep your subs off the schedule. If a tool's coordination value evaporates the moment you'd have to pay for outside users, its pricing is fighting its purpose. This is a big reason field-oriented look-ahead tools — LookAheadWall included — lean toward models that don't tax you per external collaborator; getting subs onto the weekly plan is the entire value.
- Weigh value, not just price. A platform that costs more but actually gets adopted in the field beats a cheaper one nobody opens. The most expensive software you'll ever buy is the one your crew ignores.
- Negotiate — quietly, they expect it. Multi-year commitments, larger deployments, and end-of-quarter timing all create room to move on price, waived setup fees, or free training. The list price is a starting bid, not a fixed cost.
The bottom line
Pricing models aren't good or bad in the abstract — they're good or bad for your situation. A per-project model that's a bargain for one big tower is overkill for a remodeler juggling ten tiny jobs, and a per-seat model that's cheap for a small office turns punitive the day you try to bring your subs onto the plan.
Do the boring work up front: list your must-have features, project your user and job counts three years out, drag every hidden cost into the light, and make each vendor price against your reality instead of their preferred definition. It's the same discipline you'd apply to a subcontractor bid — you're just reading a different kind of scope. Get that right, and the tool that's supposed to make your weekly work plans and trade flows run smoother won't turn into the line item you dread on renewal day.