Ask HN: What is the best way to build an app when the API is not finalised?
My company makes native Android and iOS apps for our customers. A regrettably large percentage of the time, the customer will insist on 2 things: 1) that they will take care of the API/backend architecture and data for the app 2) That we start development on the app BEFORE the API is done
I feel that #1 is quite reasonable, as the customer often has ingested their own user data somehow and wants to keep control of it. The problem comes with #2, which has caused no end of headaches for us.
Things we have tried: -Making our own quick’n dirty internal test servers that returns mock data that we guess is reasonably close in format to what will actually be provided by the actual API. Often, we guess wrong. A request that returns multiple objects is often broken up by the customer API into several requests, or vice versa. The end result is a LOT of refactoring, headaches and wasted time once the real API is available.
-Creating static views that just show mock data from the app internally, and not even messing with requests to an internal test server because this is bound to change (see above). The problem with this, of course, is that there is a lot of work to be done once the API is actually set up. Crunch and stress ensues, as the customer will often deliver the API close to the deadline.
So, my question is, what is the best practice for dealing with this kind of situation? Obviously, in an ideal world, we would simply not start work on a project until the customer has delivered a working test server, or at the least some API documentation. I have been told by the sales guys that this is not a reasonable expectation, so a better technical solution is needed.