How do you develop software without acceptance criteria?

An iterative process will achieve this nicely, without detailed specifications.

Simply create a sketchy prototype, ask for feedback from the customer, make changes based on the feedback, and repeat this process until the application is completed.

Whether the customer is patient enough to do it this way is a different question. Some clients and developers actually prefer this process; since the customer is always hands-on, he'll (eventually) get exactly what he wants.

It should go without saying that you're not going to work a fixed-cost contract this way.

If what you're saying is true and the spec is nowhere near good enough for you to even start (and you are being honest in this appraisal), I recommend this aproach:

1. Read the sketches and the "sketchy" spec that you have been given.
2. Write your own spec to a level that is just enough for you to be able to code. You may have to make a ton of guesses.
3. Show your spec to the customer for review. Note the parts that they like, and get more information on the parts where they think you've gotten it wrong.
4. Repeat steps 2 and 3 until you and the customer are in sync.
5. You now have an adequate spec.

If your customer was right when they said "it will be easy," then this exercise should be a piece of cake.

If your customer was wrong and in fact there are all sorts of gotcha's and gaps in the requirements, your draft specification will quickly illustrate the problem and communicate to them that they were wrong (without you needing to point a finger or argue) since it will be right in front of them and obvious. Also, your spec will serve as a great discussion tool for resolving those ambiguities, and will serve as a record of key decisions as you revise it with their feedback.

The product owner handed you a prototype; hand him back better ones (until you are done)

It sounds like you’ve been provided a paper prototype to start off the project. That’s not a terrible beginning. I suggest you communicate back to the business owner in the same language, by providing progressively capable prototypes.

Your prototypes should start with paper, move onto digital mockups, and then get built with “real” technologies.

Treehouse has an excellent guide for this, which concludes:

The wonderful thing about prototyping with a framework is that the prototype often just becomes the real site because the structure and styling are already in place. There’s no need to recreate the site from scratch if it’s going to use the same framework.

You may wish to provide a formal specification as well, especially if you remain worried about getting blamed for a bad result. But you will probably get more feedback from the prototypes.

Collaborate with your testers

If this loose process is a new thing for your company, your testers are probably even more at a loss than you are, and may be looking to you for guidance. You’ve got to get some of their time early in the process. Let their boss know you are trying to help them provide a meaningful test without receiving formal acceptance criteria.

Find out if the testers have anything firm they need to provide, like proof-of-testing documentation, which you can “back into.”

Try Test First Design

Since you have no formal requirements, getting test cases to develop towards would provide some structure.

Get yourself a passing familiarity with Test First Design and/or test driven development and provide guidance to your testers on the process as needed. For a quick project like this, you don’t need to become expert at the process. But using a proven methodology will reflect well on you and your testers.

Stick to standards, especially for UI

Choose a standard UI for your site and don’t customize it unless/until directed to. I don’t know what platform you are developing for, but Bootstrap or Google Material Design are two examples.

Communicate, but don’t pester

I would suggest sending one email to the product owner a day. Only send more than that if it’s an emergency.

If you have questions, describe how you will proceed if you don’t receive guidance. For example:

Will the users of this app need to access it with mobile devices? Right now we are assuming this will be a desktop/laptop only system.

Don’t panic

I’ve been involved lots of projects for folks who didn’t know the term “requirement.” Most were successful. Hands-off product owners give you the latitude to build great solutions.

Note, some project owners in these projects were impossible to please and hid behind the “I’m too busy to...” excuse for their incompetence. But most were “delighted” with the end results.

A project is the act of reducing uncertainty until certainty is achieved:

• You always start with some degree of uncertainty in the requirements. Sometimes there are only a few ambiguities. But sometimes, on the contrary, you have only very sketchy requirements, and you have to work them out as part of the job.
• You have to gradually reduce this uncertainty (successive rounds of analyse, design, implementation), detailing/ refining user stories/use case, designing and implementing your system.
• The definition of the test scenarios and cases, as well as the acceptance criteria are just a way to reduce uncertainty about quality and correctness (among other). They may have to be elaborated progressively during the project (fore example, once the customer has a better understanding of his own expectations and requirements).
• At the end, a sufficient certainty is reached : the customer gets a tested product that fits his needs and can be used.

This rule is simple: the sketchier the initial requirements, the higher the uncertainty, and the higher the time necessary to perform the tasks, and so the higher the resources and costs.

The question is then about what the contract foresees, and about who's willing to pay for the additional effort... So who is going to specify the test case and criteria (normally the user; but can you refuse if he asks you to do it and take his responsibility on the outcome ? )

"There are no regular scheduled meetings". Well, why don't you start by scheduling regular meetings then? The fact alone that you have multiple product owners guarantees that your project will NOT be easy, as each of those people WILL have conflicting requirements that MUST be discussed in person with all the stakeholders present.

Additionally, I really, really, really recommend you keep a detailed decision log. At the very minimum you write down everything that someone has decided, with the date and a list of people who were present when the decision was made. Even better if you can write down WHY something was decided the way it was. It doesn't matter if it's a file on your PC, a page in your intranet wiki, or a notebook on your desk. The log protects you and the project: when a tester says some item "fails", you can point out that it was decided that way with these people, and it's not your problem but between them and the testers. If this leads to the specs being changed then fine, but at this point they cannot expect to meet any deadline they had in mind -- or they must cut the scope somewhere else.

You need a detailed, verifiable spec before you can start writing code. That's a fact, and there is no getting around it.

If nobody else is willing to write that spec, then the developers have to write it. So you get an incomplete spec. You turn it into a complete spec (which means "this is what I'm going to implement unless someone else tells me not to"). You hand that spec to the stakeholders and give them a chance to modify the spec. Only a chance to modify the spec - not unspeccing it for example by saying "I don't like it this way". At that point, it's your spec, or they can supply a different spec, but not remove the spec.

It may be a good idea to get a quick review from your colleagues who might improve the spec. But anyway, you have a spec, you write the code accordingly, the testers test accordingly. And you have done your job: You had a spec and implemented it. If the spec is not what the customer wants, that's straight the responsibility of the product owner or the customer who couldn't be bothered to write a good spec.