Essentially, in a software development project, there are three variables we can play with: quality, scope, and timescale (which is directly linked to cost, both in terms of development cost, and opportunity cost).
Quality is the easiest one to cover. Most of the time you don’t want to muck around with quality, though, by not acknowledging it explicitly, it’s often the one that’s sacrificed. Dropping quality is essentially an exercise in deferring cost. If we cut corners, then we’ll build up technical debt, which will have to be paid off later. So dropping quality increases the long term total cost of ownership, because it’s harder to fix bad code that customers are already dependent upon than it is to write good quality code in the first case. One way to trade off quality vs opportunity cost (speed to market) is to explicitly accept that we’re building a prototype in order to test the market, and that the prototype is likely to be thrown away when we build the ‘proper’ system.
So I guess the first question is: are we building a prototype to test the market, or are we building a production quality system?
Scope is the features that we’re trying to build. We can easily muck around with that by slimming down features to the absolute minimum required for the MVP. The best way to do that is that I’m regularly feeding back to you on the details of what’s easy to implement, and what’s a little more tricky. This is much easier done at the micro level — for example, chances are it’ll take a couple of days to get drag and dropping of orders between Tello-style columns, so we might decide that a button (which will take an hour or two) is a better bet for now. It requires quite a bit of up front effort to explore all these things in advance, so I much prefer to just bring them up at the ‘last responsible moment.’ (That’s one of the tenets of the eXtreme Programming development methodology, that we defer decisions to the last responsible moment, because that allows for the best decisions to be made, while retaining the most flexibility.)
The final thing we can play with is the timescale. We could add more developers to the project, thus getting to market more quickly and reducing opportunity cost. We can reduce scope to reduce the cost. If we’re building a prototype, we can reduce quality to reduce the (initial) cost.
To my mind, the best way to work is to define a fixed budget, then to play with the scope to make sure we get the highest priority work done within that budget.