Will AppGyver support my app idea?

I would like to build an app with the following requirements and am wondering if my requirements are supported and/or what high-level trade-offs or architectural considerations will need to be made to be successful on the platform.

  • App users will register, sign-in, add and track their individual collection of widgets
  • Widget have custom metadata, including custom images uploaded by a user
  • Users can browse others users’ widgets
  • Users can make and respond to widget trade requests
  • Users can rate transactions

It’s not too unlike craigslist or OfferUp except it’s not as broad in terms of the kinds of widgets being traded or sold.

Secondarily, I would prefer to use a 3rd-party as my primary source-of-truth database (like AWS RDS or my own SQL db), but I’m open to using AppGyver’s data platform so long as I can easily migrate my data whenever it becomes needed.

Is this kind of widget trading app feasible with AppGyver? Are there any challenges, limitations or considerations that I might need to keep in mind specific to how AppGyver works when designing the app?

Thank you!

As long as your backend supports all the necessary requests via REST APIs, there’s nothing to stop you – this sounds like a very good match for Composer’s capabilities.

What do you mean by my own backend? I know what a backend is, but why must I have my own? Are you saying that I can’t build the data brokering / messaging within the app?

Am I understanding that AppGyver only provides a way to build a UI ontop of an existing API?

At the moment, the app builder is very much focused on frontend, so instead of coding a React web and a React Native project by hand, you can use Composer. You can get started with the AppGyver Auth for authentication and AppGyver Cloud Storage for data, but for a production-grade app, you’d want to use your own backend through the REST API integrations you can set up in Composer.

We are working on a full Backend-as-a-Service offering that will seamlessly integrate with Composer, but that’s still some months away.

Ah, that’s a real bummer. I’d argue that the AppGyver marketing is misleading. It says right on the homepage: “You will never go back to coding.” - that isn’t true since AppGyver is designed to work with a backend that presumably many people, myself included, will need to code.

Anyway, you answered my question and I appreciate that. Have a good one. I’ll keep an eye out for that new service.

Yeah, fair enough feedback, I can see the confusion – it is very clear to us that once we can offer a comprehensive backend-as-a-service functionality, the out-of-the-box use cases become much wider, so we hope to get there sooner than later!

We have worked to make the REST integrations as straightforward as possible (and the configurator doesn’t require coding), so if you’re using e.g. Airtable or some other no-code backend platform for your APIs, then the whole fullstack development experience IS something where you don’t have to go back to coding. :slight_smile: But your comment still stands!


At @iheartbio, while many backends require some coding there are some few ones that require no coding at all.
Take a look at Bubble (personally will recommend this) and Backendless.

You can use AirTable to store the data and it’s pretty easy to pull data from AirTable -without needing to code- into AppGyver. I made exactly something like you are describing (browse and trade widgets with matching of categories and varieties of widgets), but switched to another platform for certain reasons. But it’s certainly possible to implement with AppGyver. I launched an alpha this weekend. Message me and we can discuss.

Sorry for taking such a long time to reply. I appreciate the responses. @Harri_Sarsa, I’ll be sure to keep an eye out for that backend service. Sounds really interesting and as a software engineer, I’m curious to hear how it’ll be architected.

@SeanHoots Thanks. I’ll check those out!

@Nihal_Parkar I’d love to test your app and hear what you’ve learned that might help me save some time. I’ll shoot you a pm now.

I realize this thread is already a couple of months old, but as I search for the right low-code / no-code platform, I came across it. Candidly, I’m currently reviewing a variety of tools such as AppGyver, Mendix, WaveMaker, bldr, retool, etc.

For context: my career spans several generations of code development and technology – but I’ve also focused my own, and my teams’, efforts on Rapid Application Development (RAD) tools. When mainframe developers would spend two years building mainframe applications, my teams learned APL and cranked out super slick user friendly applications in 2 or 3 months. When Windows developers were wrestling with the complexity of C++ app dev and slow compile times, my teams used Borland Delphi to create gorgeous compiled native Windows apps in a fraction of the time.

I’m looking for the same concept now with low code – and no-code with an option to tweak internals when needed – tools. It seems that the tools I mentioned, and many others, hover around the area, but seem to either fall short in one or two respects, or have a pricing model that limits practicality of the solution, or introduces a level of vendor lock-in that many CIOs will find onerous.

I suggest that the low code / no code vendor who gets this model right will win an enormous market.

It seems that tools like AppGyver, Mendix, Bildr, Bubble, etc. get the UI portion down nicely. An immediate red flag for me, though, comes up when I see that need to bind app components to either REST API’s, a vendors proprietary data storage, or only one or two 3rd party DBMS’s. API’s require coding. They can certainly offer benefits, but also limit app developers to only the functionality and data views that the APIs publish. Horribly limiting. For contrast – I urge all of you to look at the way tools like Delphi (originally Borland, now Embarcadero – brilliant beginning and architecture, but poor business practices killed their market position, and now their pricing is suicidal), and also look at Retool – I mention these both, because they follow a similar model: a simple but effective UI designer, data “controls” (grids, drop downs, etc.) that bind with data “sources”. Sources can be a data table, e.g., from any relational database, a SQL query, etc. The is NO NEED to have a developer write a REST API. You can do it / use one, when needed, but by default, it’s simply not an issue. This speeds development significantly, removing yet one more layer between the developer and the end result. I urge vendors to look at the development cycle / model for tools like Delphi and Retool.

Finally – pricing: Platforms that tie pricing to arbitrary metrics like, “number of items”, “number of rows”, etc., take themselves out of the running immediately for a huge subset of users. One of my teams is building next-generation pharmacovigilance / drug safety software, and the databases we’re using typically have millions of rows. Tools like Retool look great – but concern me greatly with runtime licensing tied to a per seat basis – that truly limits it to in-house apps, but make it infeasible to deploy for a million user publicly accessible application. Why would you, as a vendor, create artificial barriers that limit your adoption?

I urge vendors to think about the whole market, and about your user base and all the use cases. I see wonderful innovation and creative thought across the market, but a certain degree of myopia that’s limiting the potential of virtually every product in this space as of today.



Sorry for taking a while to answer!

For the first part – we fully realize that telling developers to “just to use REST APIs” is not a good solution, and we are hard at work on a BaaS solution that will enable developers to create both new databases and other backend logic without coding, as well as easily integrate to existing 3rd party data sources.

For the second part – I completely agree about the pricing. That’s why have a free tier without any limitations if you are under $10M USD in revenue, and even the AppGyver BLACK enterprise licenses do not have any per app/seat/etc limitations, so that you can take full advantage of the platform without having to wonder if your app hits some arbitrary limitation.

Thanks for the note Harri. This is very promising. The scenario my current team is in has us looking to home in on low-code / no-code platform now. Unfortunately, while AppGyver’s overall model sounds ideal for startups, it also sounds like the current state requires a middle tier developer to straddle the gap between database and application and write the REST APIs. In the short term, that would entail the cost of the developer’s time for that, the limitations to exploratory development that come from having to define a narrow set of APIs, and the additional architecture and project management / coordination tasks this extra introduces.

No doubt you’re aware of the competition. I just suggest that if your team hasn’t looked at these for comparison / ideas, it would be worthwhile to see how platforms like retool and Delphi handle the interface between application code and database.

Finally - do you have any sense of the timeline for the BaaS development?


Sorry for the long response time! We hope to get something in closed beta soon (weeks rather than months, hopefully), but no timeline to stick to yet.

Hi @Harri_Sarsa, Im new to AppGyver and trying to get a grip if it will work for my application which Im planning to remake. It is a quite simple job-board which require sign-up, login, handling user profiles (CVs), security, privacy and such issues. I am confused with the term backend and what you mean with it. I see that AppGyver enable design of logic flow (which I define as backend) and a database for demo purpose. So what exactly do you mean by custom backend/own backend and what is included in the upcoming BaaS? Thanks Mario

Harri -

I’ve built many enterprise applications - as well as the framework and toolset on which they were built - over the last few decades, and I’ve both led, and participated in, numerous betas. If you have room for one more (admittedly novice AppGyver user), I’d be interested, especially as this may help give me a sense of what’s coming, how close it might be, and whether it’s sufficiently close to our needs and imminent so we should postpone our architecture / tools decision to wait for it.

Let me know!

Jon Strong

Sorry for the long delay, sent you a DM with more info!

Sorry for not replying to your question, missed it! The upcoming Cloud Mesh product will make it possible to build and run custom logic flows in your backend (allowing essentially limitless power of expression), while also providing a hosted (production-grade) database and user/group management. We’ll talk about it more soon!


Thanks for the positive reply @Harri_Sarsa. Will your upcoming backend enable low/no-code to customize logic or is it essential to use JS or other coding language? Also, if one would use your current built in db now for development purpose - how cumbersome would it be to migrate this schema to the production grade db once it is available? Im evaluating whether or not to start up with Firebase as backend or just focus on front-end until the upcoming AG-backend is ready to launch. Very excited about it. I assume hosting would remain at AWS right?
Best, Mario

1 Like

Sorry for the delay! The new BaaS will be no-code, with logic constructed from flow/formula functions (you will have the ability to use custom JavaScript and npm packages too), just like logic in Composer.

We’ll probably create some sort of migration tool for existing AppGyver DB users, but using Firebase now will probably give you the needed versatility, as we have no definite release date yet.

Hosting is planned to be on AWS, yes!

Hi Harri,

Thanks for your continued support throughout the forum - really excited to be using AppGyver (AG).
Could you also send me instructions on how to join the beta BaaS please? I’m currently building my app with Xano as a backend, but if I can keep everything in-house (within AG) from the beginning, I’ll save myself a lot of time in the long run.

Thanks in advance!