That really depends on the OPs requirements. If they already have a working application, changing the database backend (or going farther and make it configurable) can be a huge pain. That starts with simple stuff like timestamp handling between different databases and support for different basic features (foreign keys, typecasting, upper/lowercase conversion functions, unicode handling etc). But even slightly more complex SELECT statements can run into troubles, SQL has many different dialects.

Also, SQLite doesn't support partitioning, XML and JSON handling (other than "as text") and server side scripting. If an existing application relies on any of that, a major rewrite would be required.

As for "running smoothly out of the box", SQLite is a bit problematic as well. For one, if your application uses more than a single table, it pretty much has to manually activate correct handling of foreign keys everytime it opens the database:

PRAGMA foreign_keys = ON;

This will increase memory requirements and slow things down a bit. But running a database without proper foreign key support is just asking for trouble.

I'm not saying SQLite is the wrong choice per se, it really depends a lot on the circumstances. If OPs project is a blank slate/green field project that runs a single process SQLite a good choice (i use SQLite for similar stuff). But if it's "porting existing, multi-process/multi-thread software to a different hardware", the situation is a lot more complicated. We don't know the design of OPs software, we don't know how complex and mature it is. But since they plan to hand demo systems out at trade shows (to potential customers, probably?), i have to assume that the demo project has more than "trivial" complexity, has been tested a lot already and it has to work without any major new bugs.