No code hits a barrier when UI and DB requirements diverge. Usually for internal apps two separate teams/devs are involved, so it happens pretty soon. For instance, a simple print human readable status for the enum field in the DB needs code. Throw in REST API calls to internal/external services in this mix and the need for code is almost immediate.
Last year I built multiple Retool apps, all simple ones, but they needed code for data transformation and joins. What got in the way were operational items:
- Punch a hole in our firewall to access internal APIs.
- An internal Retool deployment was out of question since their install isn't light (requires a Postgres). Btw, Superblocks solve this problem quite elegantly by separating the control and data plane.
- Code reviews and testing were a constant challenge.
Congratulations on the funding! I built multiple unusual internal apps for our product last year. Retool is now in my list of "must have" for any thing I build.
The build process took a bit of time and I had to hire an expert on Upwork. Not everyone might persevere. A gallery with examples of varying complexity would make the sell easier.
Don't quite agree with your statement "As the mobile app market continues to mature it will strain against its walled garden confines more and more". On the contrary, I feel that consumers will continue to appreciate walled gardens for their convenience, quality and trust worthiness.
I guess this argument will be tested by the Mac app store.
Last year I built multiple Retool apps, all simple ones, but they needed code for data transformation and joins. What got in the way were operational items:
- Punch a hole in our firewall to access internal APIs.
- An internal Retool deployment was out of question since their install isn't light (requires a Postgres). Btw, Superblocks solve this problem quite elegantly by separating the control and data plane.
- Code reviews and testing were a constant challenge.