Wait, wait. What is the appropriate unit of work for programming?

Lines of Code? We've been down that road, and it doesn't work well. Especially if you improve the project by deleting unneeded code - did you just do negative work?

Features? Some features are wildly more work to implement than others.

Bug fixes? Besides not being a sufficient measure of work making new code, making a bug fix the work metric penalizes conscientious programmers who find and fix all their bugs very quickly before they check in, or if they report them then they're wasting time writing about bugs that took less time to fix than they did to write about.

I think in an ideal world programmers should get paid by work units, but I don't think there's a way to measure it that doesn't create more overhead than it is worth. In the end, people get paid by the hour not because it's be best way, but because hours are easy to measure.

Think of employees as subcontractors. Their basic monthly salaries are your costs of having them on standby to work on your assignments. Then you can (more or less) calculate the value of a unit to your company / project and that's what you pay for it. Roughly speaking. So "unit" won't translate into "work unit" (like LoC and similar quantities) but into "subproject". And so we're talking about capital budgeting. A good hacker can understand and apply this creatively after some good books or courses (or the VC advisors provide the knowledge), 'cause in the end it's just some basic concepts + formulae.

Careful about paying per unit of work. Your workers might throw quality out the window in order to get more quantity and thus more money...

Specify the unit's quality. Payment depends on compliance to the specification. One can agree to pay a basic monthly salary (we're talking about employees who are motivated by some income security) and make all else a variable income. One needs to find of course the balance between loyalty to the company (monthly steady income stream) and productivity (income by units). So it depends on both the startup and the workforce where to set the priorities.

Measuring quality of work in a startup is equivalent to predicting in the future how much of a contribution some work is making on the outcome.

Conformance to rigid specifications is not the way to go.

My entire text was "roughly speaking" because it depends on the startup's context and the founders' knowledge and abilities. I'm not talking about book-long specifications, but for sure you should have some requirements on unit functionality and code quality. And the unit's value is not about predicting the future but derives from your sales plan. This is about a startup already in a situation when it hires employees, so they usually have some historic data on the market and their own performance to base their guesses on.