What is base development capacity (1×)?
A package contains development capacity — not hours, not calendar weeks. You spend it on the features at the top of your roadmap. Base capacity (1×) is our unit of measure for it.
In plain terms: 1× capacity in changes
As a rough rule of thumb, one base development capacity (1×) is enough for one large change or about 20 smaller changes. Larger packages contain a multiple of that: the 3× and 8× packages deliver correspondingly more functionality.
"Large" and "small" are not a gut feeling but the result of a professional assessment. What makes one feature small and another large comes down to its complexity — and that has surprisingly little to do with the number of screens or buttons.
Base development capacity
1 large change
20 smaller changes
- Change 1
- Change 2
- Change 3
- Change 4
- Change 5
- Change 6
- Change 7
- Change 8
- Change 9
- Change 10
- Change 11
- Change 12
- Change 13
- Change 14
- Change 15
- Change 16
- Change 17
- Change 18
- Change 19
- Change 20
Why valuation is hard
Not every feature is the same size.
Two features can sound identical on paper — and differ tenfold in effort. The effort rarely sits where non-experts expect it: not in the number of screens, but in the complexity behind them.
That is why we value every feature along a few but powerful complexity drivers. They determine whether a feature is "small" or "large" — and therefore how much capacity it draws from your package. Your curator assesses this transparently before a feature goes into implementation.
The four complexity drivers
What makes a feature large
Complex business domains
The more tangled the business rules, the more hides inside a seemingly small feature.
Some features look simple on the surface but carry a dense web of business rules: tax and billing logic, regulatory requirements, tariff and discount models, role and permission concepts, industry-specific edge cases. A "create an invoice" feature in an insurance or logistics context is something entirely different from the same feature in a simple online shop.
Why it drives valuation
Every rule has to be understood, modelled cleanly, aligned with you and tested against its edge cases. It is this domain depth — not the lines of code — that determines how much capacity a feature consumes.
Complicated technical solutions
Demanding technology under the hood costs more capacity than an off-the-shelf building block.
Features that require real-time processing, concurrency, integration with foreign systems, involved data migrations, offline capability or special performance and scaling requirements need thought-through architecture rather than a ready-made block. An interface to a temperamental third-party system can be more work than the feature itself.
Why it drives valuation
Such solutions demand design, prototyping, careful error handling and more intensive testing. The risk and the diligence required rise — and with them the capacity we set aside to deliver a robust result.
Large code base
The more mature the product, the more consideration every new feature demands.
In a fresh project a feature stands on its own. In a large, grown product every change has to be woven into existing structures without breaking anything else. More touch points, more dependencies, more places where something can break — and more existing tests that must stay green.
Why it drives valuation
The same feature is more expensive in a large code base than in a small one: getting familiar with the existing code, regression testing and integration all cost capacity that simply does not arise on a greenfield.
Exceptional UI design
A standard form is built quickly — an outstanding experience is craftsmanship.
Functional, standard interfaces from our toolkit come together fast. Something exceptional, on the other hand — bespoke interactions, fluid animations, data visualisations, pixel-perfect brand work, considered accessibility and flawless behaviour across every screen size — is design and engineering fine work.
Why it drives valuation
High design ambition means design iterations, attention to detail and extra testing across devices and input methods. This polish effort flows directly into the valuation of a feature.
From capacity to package
You buy capacity in the form of a package and spend it on the features that matter most to you. The tariff sets how much capacity a package contains — expressed abstractly as a multiplier: Minimal (1×), Performance (3×) and Max (8×). Higher tiers deliver more functionality per package.
You can switch the package size on every booking. Unused capacity expires 90 days after purchase.
Tell us about your idea.
In the first video call we work out together what is large and what is small — and you receive your first working version. Free and without obligation.