The time cost of learning a tool, measured

Three months into a marketing site rebuild, a five-person team we were tracking for an unrelated piece had produced two finished pages. Not because Webflow is slow software — it isn't — but because nobody on the team had built in it before, and "building in Webflow" turned out to mean learning the Designer canvas, the CMS collection model, class-based styling, and which of the platform's four separate billing axes their plan actually covered, roughly in that order, roughly all at once. The subscription was $15 a month, billed annually. The hours spent getting to a state where a page could be built without stopping to look something up were closer to fifteen per person. Nobody had budgeted a single one of them, because nobody asks "how many hours will this take to learn" before signing up for a tool. They ask what it costs.

That gap is the subject of this piece, and the honest place to start is with the objection to measuring it at all: learning time is soft. It's estimated, by whoever is making the case, and can be stretched or shrunk to fit whatever conclusion someone already wanted. A subscription price is a fact printed on an invoice; an hours-to-competence figure is a judgment call about when someone stopped needing to look things up — exactly the kind of number a consultant can lean on to make any tool look expensive. We take that seriously, which is why the figures below come from the same fortnight-minimum, same-brief method we use for every tool we write about — described in full in how we test a tool before writing about it — rather than a single afternoon with a trial account. The hours are still estimates, but at least estimates made the same way every time, against the same task, by people with no stake in the answer.

What we logged, on four tools built to the same brief

The brief was identical across all four: a one-person portfolio site, five sections, one contact route, published to a live URL. Two numbers per tool. First useful output is the point where a real, presentable page exists — not a blank canvas, not a half-filled template. Competence is the point where the next similar page takes no more reference-checking than a tool the person already knew would need.

Tool	First useful output	Competence	What ate the hours
Carrd	under 30 min	under 2 hours	almost nothing — one page, no data model
Wix	about 2 hours	roughly 6 hours	drag-and-drop precision, business-tool sprawl in settings
Webflow	about 4 hours	12–15 hours	the CMS collection model and class-based styling
WordPress (self-hosted)	about 3 hours	15+ hours, ongoing	which of thousands of plugins and themes to trust, and staying current

The shape that matters is not any single number, it's the gap between "first output" and "competence" on each row. Carrd barely has one — there is one kind of page and one way to build it, so getting to a good result and getting to a repeatable process are almost the same moment. Webflow's gap is the widest of the three builders because the thing that takes time isn't the interface, it's a genuine content-modelling skill: understanding what a CMS collection is, when a field should be a reference versus a plain text entry, how classes inherit. That skill transfers to the next Webflow project, which is exactly why it's worth calling "learning" rather than "friction." WordPress is the outlier for a different reason. Installation has been quick for years — the vendor's own docs still describe it as under five minutes, though the old "famous five-minute installation" line has quietly been retired — but the CMS was never the bottleneck. Competence means competence in an ecosystem of plugins and themes that keeps moving, so the hours never fully stop the way they do on a closed platform. Open means the learning curve doesn't have a top.

The formula that turns hours into a decision

Once you have a competence estimate, the arithmetic is one line: hours to competence divided by hours saved per week once competent equals weeks to break even.

Take the Webflow team from the opening. Call it fifteen hours to competence, and say the tool genuinely saves three hours a week once everyone knows it. That's a five-week payback period — reasonable for a site the team will maintain for years. Run the same arithmetic on a tool adopted for a single six-week campaign microsite instead: fifteen hours to learn against three saved a week is nearly three of the six weeks spent purely breaking even, before the campaign has produced anything. Same tool, same learning cost, opposite verdict — the only thing that changed was how long the tool was going to be used for. This is where the money and the time lines meet: on an annual site plan, Webflow's Basic tier runs $15 a month paid annually or $25 paid monthly, and that gap between billing cycles is itself a bet about how long you'll keep the tool, the same bet the break-even formula makes explicitly. Prices checked August 2026. The worksheet for combining a figure like this with the rest of what a tool costs is laid out in what AI tools actually cost; learning is one line of five.

The formula is deliberately crude — it doesn't discount future hours, and it assumes the saving is constant. Use it anyway: the value isn't precision, it's that running the calculation forces the one question people otherwise skip — how long is this actually going to be used for. Half the tools brought into a team fail that question the moment it's asked out loud, which is the point of asking before the subscription starts, not at renewal.

The cost is paid once per person, not once per team

The number in the table above is per person, and teams routinely price a tool as though it isn't. A five-person team adopting Webflow doesn't pay fifteen hours of learning cost once — it pays it five times, because competence doesn't transfer between people any more than a gym membership does. The team in the opening had one person who reached competence within two weeks and four still looking things up in month three, so the honest accounting of that rollout is seventy-five person-hours of learning, not fifteen.

This multiplies hardest on tools that also charge per seat, because the two costs compound in the same direction: every new person is both a new subscription line and a fresh fifteen hours nobody accounted for. It multiplies least on tools one person operates on behalf of everyone else — a single admin publishing pages a team only ever views. Worth treating as a real design choice when evaluating a tool for a team, not a limitation to note in passing.

Documentation quality predicts the curve better than the interface does

Across the four tools, the single best predictor of how fast someone reached competence wasn't the interface on day one — every one of these has a clean-looking onboarding flow, because onboarding is what every vendor optimizes hardest for. It was whether a real question, typed into a search bar at hour three, returned an answer written by the vendor or a forum thread from three years ago describing a version of the product that no longer exists.

Carrd's documentation is short because the product is short — informative about scope rather than a weakness. Webflow's official docs are dense but current, and walkthroughs exist for the CMS specifically because enough people hit the same wall at the same point in the curve that it became worth writing about. WordPress's documentation problem isn't the core software's docs, which are fine — it's that most of what a builder needs to know lives in the changelog of whichever plugin they picked, and plugin documentation quality varies from excellent to nonexistent with no way to tell which before the project is already committed to it.

Sunk learning cost is why bad tools survive the audit

The hours already spent are, by the time anyone runs a subscription audit, gone regardless of what happens next. That's the correct way to treat them and almost nobody does. What actually happens in a review meeting is someone says "we already know how to use this" as though the fifteen hours are a reason to keep paying, when they're identical whether the tool is kept or dropped — already spent either way, with the only live question being what the next twelve months of use are worth against the next twelve months of subscription and maintenance. We watched this exact reasoning keep a workspace tool deployed a full year past the point it should have been narrowed, described in Notion as a workspace after a year: not because the tool was earning its place everywhere it had landed, but because the team that had learned its quirks was reluctant to write off the hours spent learning them.

The countermeasure is to ask the audit question honestly: if this tool disappeared tomorrow and everyone had to relearn something else, would today's team choose to spend those hours on it again, at today's price, doing today's job? If the answer is no, the hours already spent aren't an argument for staying — they're the reason the question feels uncomfortable to ask.

Some curves aren't worth measuring

None of this is worth doing for every tool. Carrd's competence gap is under two hours because the product has one kind of page, one layout model and no content system to learn — running a break-even calculation on something that short costs more time than the learning did. Same for any tool where the feature set fits on one screen: a link-in-bio page, a single form builder, a URL shortener. Rule of thumb: if first useful output and competence are less than a working morning apart, skip the arithmetic and just start. The formula earns its keep where the gap is wide — CMS-driven builders, anything with a data model, anything a team rather than a person will maintain — and wastes the very hours it's trying to protect everywhere else.