I've had 2 friends start revenue generating MVPs on Bubble.io
One is a Cameo-like platform for LatAm, the other is a TikTok like short-form audio app .
I've been incredibly impressed by the platform and extensibility. If you have basic coding skills I think it's much more powerful than Webflow or other platforms.
I believe for the case of SaaS, at worst it's just not possible, and at best the odds of identifying and building a successful SaaS tool with no code is probably orders of magnitude lower than otherwise.
That being said there are many people who have built businesses around helping companies with setting up WordPress and Shopify sites, which are all about navigating their admin panel, dashboards, etc. You would not be the first person to help set up websites with no code.
Sure, look at any low-code platform that has an ISV partner program. You'll find plenty of success stories. My company even started that way, and ended up growing over 15 years and getting bought out before we even looked at going full-stack for our products. We're just shy of 20 years since our initial launch, and just now finally coding at our first full-stack version.
To be fair, we did start adding custom code after the first few years, but we went a really long way before losing the last of the low-code platform.
Friend of mine has been thinking to start a no-code engineering school to teach people the skills required to build no-code products for exactly that reason
Don't do this. I know that sounds like bad advice, but if you aren't comfortable working with lower-level design paradigms, who's going to fix things when something goes wrong? You'll eternally be in debt to engineers who are happy to take your rudimentary API contracts and make free money. Trying to be an entrepreneur in an area that you don't have experience in is a money pit.
Yeah, but that would be a pretty crappy low-code platform if when things went wrong, they did not handle it, and instead told their customers to go hire coders.
Someone's getting paid to fix your program, whether it's a "computer science consultant" or their premium service package (probably $3,995/ticket, if it's anything like how Microsoft/Canonical runs their business).
It's easy to say that, but what do you expect the platform to provide? If the platform makes operating your business so trivial that they provide all functionality baked into the product, I would suggest that your business may lack novelty, and therefore it may also lack competitiveness.
"No code" doesn't mean you don't have to implement things yourself. You are simply limited to the platform's baked in abstractions in exchange for "not having to write code".
Your services may eventually not map well to the capabilities of the platform, and it may cause problems. In such cases, the easiest and likely best solution is to offload functionality to a private server running custom code that interacts with the interfaces to the existing platform.
The whole "no code" thing is spun as "empowering entrepreneurs", but there is a philosophy underlying it that implementation details don't matter, and programmers aren't needed. It may be true for some businesses who are in non-technical sectors, but if you are selling digital services themselves "no code" will only take you so far.
100% disagree, and I've built, managed, sold, advised, etc. etc. 100's of tech companies.
Starting a tech business on a low code environment is a great idea. In fact, is probably the best idea since it means iterating fast, easy to identify functional requirements and gets you to market fit ASAP without breaking the bank.
Running a tech business at scale on a low code environment is a whole another topic (the OP explicitly mentioned "built").
TL;DR - Unless you're building hard tech (AI platforms, VR, etc.), then low code environments are great ways to build businesses.
> then low code environments are great ways to build businesses
Eeeehhhh - it depends on where and how your business delivers value. As others have said, the problem with low-code platforms is they're generally proprietary, which means it's much harder to wean yourself off once you get started - though that's not my main concern: my main concern is that low-code platforms necessarily mean ceding control over your product's E2E: if you accept that for the productivity gains from not having to get bogged-down in the details, sure - but for a lot of stuff it's a very limiting factor.
My current company's focus is a small suite of domain-specific line-of-business SaaS apps - nothing special there. It does mean that our entrenched and incumbent competitors built "unsexy" ASP.NET WebForms (ew) pages over a decade ago and haven't maintained them - or they're relatively modern but built on-top of heavy SPA frameworks that ultimately detract rather than benefit the E2E UX (an egregious example is a competitor that has a traditional SSR web-app, except they load Angular2+ in every single page-load... it's stuff like that which makes users develop negative sentiment around a web-application.
Another anecdote is a simple reporting system built-in to one of our products: again, it's nothing special: just a data warehouse in Azure with some clever hand-written SQL queries to populate some simple HTML tables with ChartJS thrown-in for good measure - and one of our biggest customers' buyers was completely floored by our demo - I thought he was being sarcastic or facetious in the meeting but it turned out that they were using another of our competitors who built their similar reporting functionality using a low-code-ish platform where the web-service is a dumb store of data and the client JS code has to retrieve and process all the data itself... (with no multi-tenant access-controls either) so it took 30+ seconds (and thousands of AJAX requests) for their report to load.
...now you can argue that my anecdotes concern companies that either let their product go stale or had an incompetent (or under-funded and over-worked) development team - but that doesn't detract from my point that low-code tools and platforms make it very difficult, if not impossible, to root-out E2E issues. Having an app with poor performance is bad enough, but having an app where the low-code platform you built-on makes it impossible to address some core user-experience fault is why I have a hard line against low-code in principle. Another example of this is this one particular low-code web-app platform (no names please) which hard-codes in some old version of jQuery which then precludes bringing in other client-side libraries or third-party widgets (think: stuff like ZenDesk chat support, and their widget's bad enough already).
So yes, it's cliche: but "it's a tradeoff" - but just be mindful of exactly what you're trading-away in exchange for developer productivity. You're either the kind of company that looks at, say, Blackboard and either sees them as a success for their large user-base - or you're someone who actually used it and consequently will carry that bad-taste-in-the-mouth over to not recommend purchasing it if they're ever put a position where they make decisions about what software/systems an org buys. My opinion is that the user-experience matters, and low-code tools make it easy to ruin the E2E UX if you're not careful.
I disagree strongly with this as blanket advice. A large number of SaaS apps are primarily CRUD apps where outputs are database updates and/or API calls. No-code platforms could support many of these quite well through the first $1m + of revenue.
And I can't believe this needs to be said, but yes it can be smart to hire programmers to build 5% of your system instead of 100%.
> Trying to be an entrepreneur in an area that you don't have experience in is a money pit.
Y Combinator exists as an explicit bet against this proposition. (They publicly said they wanted to find the youngest age where entrepreneurs could be successful.) To take another, AirBnB is a good counter-example. Should the founders have been experts in programming? Data science? Recommendations engines? Hospitality? If you erect enough artificial barriers, nobody will launch anything.
I guess any tech content business would count. For example this guy below has both online classes where he teaches others how to ace a FANG interview and he also earns from his YT channel.
Would love to hear someone’s take on TechLead, especially someone informed from working inside a FANG.
I’m trying to be less judgey generally, but there were a few things in the one video I started to watch that had me giving some wild side-eye so I stopped watching and never went back.
Not really low/no-code but the Views module in Drupal lets you build very nice simple tools for customers with just a few clicks.
I've built webshops with it.
yeah Views is awesome. I've been using Wordpress for years now because that's a requirement for the agency that hired me. But I still haven't found a good replacement for Views.
I have seen prototypes/MVPs done with lowcode/nocode tools + manual processes (google forms are highly underrated for this type of stuff) but never a full business.
Kind of. I've seen a startup go pretty far (series A, at least, with thousands of customers) with Google Sheets + low code integrations with those sheets.
Unity is not entirely no-code, but it comes incredibly close. I'm willing to bet there are a handful of iOS/Android games out there with barely a line or two of custom code written.
I’m working with a startup at the moment that has put all their investment into their customer facing app, but almost everything behind the scenes is built in spreadsheets and low code tools. Can’t spill too much about the company, but think something like “get flowers delivered within 30 minutes via a fancy app”, but not flowers.
Without building in this way there is no way they would be growing at the rate they are - they would still be writing their MVP (they are now valued at >$100m in year 3, and are still supported entirely by spreadsheets as the investment in terms of focus is towards anything customer facing - they know they need to sort everything else out, it’s just everything has to be prioritised). Also their ops are still evolving so quickly that any investment in writing code to support ops is likely to slow down ops change (who need to be able to respond to issues nobody has seen before).
With tools like Airtable, you could simply export your data to CSV, though you'd lose the relationships. There are tools like bildr, appgyver etc that let you export at least the HMTL/CSS (depending on the pricing tier).
I think that the whole discussion around low-code is missing a pretty fundamental issue: most programming libraries suck.
If I need, say, authentication, why do I need to install a library and then read a bunch of documentation on how to use it? Why can't I simply plug it in (just like low-code!) and have it automatically work?
I think there is a lot of room to improve developer tooling and that the effort spent there would produce much greater rewards than developing a higher level abstraction, such as a pluggable authentication widget aimed at non-programmers.
I think libraries are complicated so that they can be flexible and support many different use cases. You could release one library for authentication that works for one specific use case, but it would be useless for all others.
As far as I have seen, so far in my career, this is all 'not invented here' stuff. Most things, like auth go from 'oh no mate, we need 10000x more complicated stuff, that Keycloak thing will never fit!' and then, 6 months later there is something like keycloak but worse, far less features, more complex but replacable in no time by keycloak without touching the keycloak (no customizing) sourcecode. But we cannot because we now invested 6000 hours into it. So now it is ours and we will continue to say it is very complicated and so nothing fits our complicated use case.
Alternatively, tell me your complicated auth flows that will not have users running away screaming and are, therefor, bad ideas and should be replaced by cookie cutter stuff. Because that is where all of these things end up.
A number of Ruby on Rails applications use Devise for basic account management and authentication. It's about as close as you can get to a cookie-cutter experience. As long as you follow the workflow, it's pretty straight forward to handle.
Drop in the plugin you want, configure the API keys, and then wire it into your User model. Then you can customize the urls, views, and emails.
You still have to read a fair amount of documentation and a lot of developers don't like the extra up-front work and reinvent the wheel because it's "simpler".
This is what we're trying to solve at Clerk, (https://www.clerk.dev) and it's been harder than we've expected, especially in regards to local development environments. Although we think we’ve made it seamless! Would love your opinion.
However, we're definitely not aiming it at non-programmers. I don't think completely general low/no-code solutions will ever take off. Everyone wants things far too custom, and at some point you won’t be able to beat the programming language of the time. Companies like retool are doing a great job in specific verticals — and I think it will always stay that way.
I think the next generation of dev-tools are going to be pretty impressive, especially with how easy and modular React components are — I’m bullish that React will become “low-code”
Because authentication is coupled to authorization and authorization is coupled to business rules and data access. If your program does not deal with business rules and data access then it is probably a single-user program (that does not need authentication).
I'm over-simplifying of course, but these things sound simple until you ask all the "but-then" and "what-if". If someone actually makes them simple in a way that still lets me cover those cases I'll be the first to stop writing authN/authZ code.
MeteorJS solved this years ago. You add a package and have everything working including oauth sources in 10 minutes flat. It was incredible. Shame MeteorJS died of his death. Sorry for your condolences.
TBH on asp.net you pretty much just follow a tutorial and you have signup, auth and users pretty quick. Let’s say this is 4 hours work for a programmer but .net newbie to set up a new project, add authentication including email/password and Google and get that deployed to azure. 4 hours from a business is a tiny amount of time. The upside over no code is owning the code and not being reliant on a dozen other indie startups for your business to continue to run
I did (& it’s been brining in good money for the past 2+ years)
I built the Castup[1] website using Webflow, use Outgrow for onboarding, Stripe for payments, Slack for communication. It’s a productized service startup in the podcasting space but I have enough knowledge of no-code tools to build a SaaS as well.
I used to work at a startup that utilized Webflow heavily for the frontend. The CEO was a designer by trade and very good with it, so he would build out all of the pages there. We'd then adapt the markup into Rails views and include the stylesheets Webflow generated and boom, working product.
It was extraordinarily fast for static content, although forms and controls were a bit more difficult. We ended up building out some primitives using Stimulus and ActionView Components to make life easier, and overall it was a surprisingly nice workflow.
Would I recommend it to others? Possibly. It worked really well for our situation where time and agility were valued above all else, but I attribute the success there in part to the way the team worked and the fact that our founder was so proficient with it.
Not using, but building. It significantly lowers the barrier of entry for new customers to use the tech.
What's important for me is that users can ramp up from drag 'n drop to coding by hand. Otherwise they might just end up feeling stuck with the tool.
I'd rather see users use and then discard our tool once they ramped up their skills, in favour of then just writing code using our tech. Much better than getting stuck forever in our competitors' rather limited toy editors. :)
Keep in mind that 2/3 of software costs are in longer-term maintenance. If the results are not maintenance-friendly, it won't be wallet-friendly. As a proof of concept or an emergency rush job, it might be okay, but don't hitch your wagon to it.
Hmm, I’m a Salesforce developer and I’d say most companies I’ve worked with have used Salesforce’s no-code tools, most very far to the core. Power retailers, broadband, banks, just about every big company. It’s an absolute mess at some point tho, but it does work.
i was an adviser for a startup that never moved past using email, slack, excel, ifttt and a little bit of cloudformation for all it's "code". they always intended to build out a "platform" but the tooling they had scaled fine and took them right to acquisition ~2 years after launch
I was (well, not sure, have not tried recently) a very experienced Delphi coder and if it is low code or not depends on your VCL palette. Most would not be: you could drag and drop screens fast but it took a lot of code beyond the very basics. However, there were a few, especially Russian and Ukraine VCL libs which had you just mess around with Properties and that was enough to create pretty complex applications. Most companies I worked with did not allow and/or wanted to pay for those.
We are! We started Lowdefy [0], co-founder here shameless plug, by building apps for customers. Our model is to build their back-office apps for them with no up-font dev charge, we just agree on a monthly fee. This monthly fee includes any changes and reporting in the future at no additional charge, as long as the scope remains the same. And they own the data in their database of choice.
The model is not perfect and does not work well for every type of process, but we have a few very satisfied customers. Just enough success to slowly grow our business and buy us enough free time to build and improve Lowdefy.
Currently it's working really well, like one gear turns the next. The apps we sell help us test and improve our low-code platform. The more apps we sell the more we invest in our platform and as a result all our apps get better, more feature rich and easier to maintain. Hopefully next, by building an open-source community around Lowdefy we can accelerate this cycle.
I tried out Lowdefy recently and it was too much yaml so in the end I just wrote my app with Vue and Buetfy. If you had a visual editor that was good I would have used and paid for that.
This is interesting feedback. Thank you! I would love to ask you a few questions about this, if you do not mind, please reach out gvw[at]lowdefy.com
A visual editor is definitely on our roadmap. Our strategy is to make the schema easy to read, write and understand. We want to ensure the dev experience of working with the Lowdefy schema is first class so that change review and version control can be as productive as possible.
Adding a visual dev interface is resource intensive can easily distort the schema quality. We figured by first maturing the schema and making sure it works well with dev tooling, we can add a visual dev interface on top as Lowdefy becomes more popular.
I made a dev tool into a small business. Came hear to rant: invest in ui upfront.
At the end, customers visit your site and you have very little time to make them go wow. Your spending a lot of attention capital when you don’t have much
Can you elaborate on what type of devtool you built?
I'm founder of a startup that develops DevOps tooling and we're debating how early to build out the ui. (We have the basics down with Vue like I mentioned.)
I can't speak for the GP, but I personally find editing code in my IDE to be a smoother and more productive process than editing any type of serialization or markup format like YAML (or JSON, or RON, or EDN to a bit lesser extent). This is most likely due to me being so used to being on the other side of those formats, or generating them with code in the first place, and not necessarily because one is "better." My IDE setups will reflect that preference, which in turn makes it stronger.
Thanks for the advice. You make a very valid point. The first version of Lowdefy had a UI, then every time we wanted to make a schema improvement we also had the tech debt of adapting the UI. As a result the schema became secondary and more and more become unreadable.
So then we really asked how lean can we make this platform to keep it agile while experimenting with the mechanics of the schema. After more than a year of that the experimentation paid off and we now have a very flexible, yet understandable schema for building apps.
But yes. Adding a visual editor on top is one of our goals - and we are getting closer and closer to making it happen.
We are building packages around WeBase [1]. As an example we have a solution for small businesses/startups that includes a website/forms/email lists etc all in one... here's a site using this solution: https://www.sbaloanshq.com/
Lots of opportunity with these tools and platforms!
103 comments
[ 0.91 ms ] story [ 222 ms ] threadOne is a Cameo-like platform for LatAm, the other is a TikTok like short-form audio app .
I've been incredibly impressed by the platform and extensibility. If you have basic coding skills I think it's much more powerful than Webflow or other platforms.
https://bubble.io/showcase
Are you allowed to share links to their businesses?
That being said there are many people who have built businesses around helping companies with setting up WordPress and Shopify sites, which are all about navigating their admin panel, dashboards, etc. You would not be the first person to help set up websites with no code.
You can read more about how it was built here:.
https://www.foxy.io/blog/how-okiefoodtrucks-is-using-foxy-we...
To be fair, we did start adding custom code after the first few years, but we went a really long way before losing the last of the low-code platform.
It's always going to be a money and time pit when you need to outsource to fix any problems.
If you don't know code, hire someone on your team who does. :)
Yeah, but that would be a pretty crappy low-code platform if when things went wrong, they did not handle it, and instead told their customers to go hire coders.
"No code" doesn't mean you don't have to implement things yourself. You are simply limited to the platform's baked in abstractions in exchange for "not having to write code".
Your services may eventually not map well to the capabilities of the platform, and it may cause problems. In such cases, the easiest and likely best solution is to offload functionality to a private server running custom code that interacts with the interfaces to the existing platform.
The whole "no code" thing is spun as "empowering entrepreneurs", but there is a philosophy underlying it that implementation details don't matter, and programmers aren't needed. It may be true for some businesses who are in non-technical sectors, but if you are selling digital services themselves "no code" will only take you so far.
Starting a tech business on a low code environment is a great idea. In fact, is probably the best idea since it means iterating fast, easy to identify functional requirements and gets you to market fit ASAP without breaking the bank.
Running a tech business at scale on a low code environment is a whole another topic (the OP explicitly mentioned "built").
TL;DR - Unless you're building hard tech (AI platforms, VR, etc.), then low code environments are great ways to build businesses.
I'll wait
advised
Thanks for the snark though.
Eeeehhhh - it depends on where and how your business delivers value. As others have said, the problem with low-code platforms is they're generally proprietary, which means it's much harder to wean yourself off once you get started - though that's not my main concern: my main concern is that low-code platforms necessarily mean ceding control over your product's E2E: if you accept that for the productivity gains from not having to get bogged-down in the details, sure - but for a lot of stuff it's a very limiting factor.
My current company's focus is a small suite of domain-specific line-of-business SaaS apps - nothing special there. It does mean that our entrenched and incumbent competitors built "unsexy" ASP.NET WebForms (ew) pages over a decade ago and haven't maintained them - or they're relatively modern but built on-top of heavy SPA frameworks that ultimately detract rather than benefit the E2E UX (an egregious example is a competitor that has a traditional SSR web-app, except they load Angular2+ in every single page-load... it's stuff like that which makes users develop negative sentiment around a web-application.
Another anecdote is a simple reporting system built-in to one of our products: again, it's nothing special: just a data warehouse in Azure with some clever hand-written SQL queries to populate some simple HTML tables with ChartJS thrown-in for good measure - and one of our biggest customers' buyers was completely floored by our demo - I thought he was being sarcastic or facetious in the meeting but it turned out that they were using another of our competitors who built their similar reporting functionality using a low-code-ish platform where the web-service is a dumb store of data and the client JS code has to retrieve and process all the data itself... (with no multi-tenant access-controls either) so it took 30+ seconds (and thousands of AJAX requests) for their report to load.
...now you can argue that my anecdotes concern companies that either let their product go stale or had an incompetent (or under-funded and over-worked) development team - but that doesn't detract from my point that low-code tools and platforms make it very difficult, if not impossible, to root-out E2E issues. Having an app with poor performance is bad enough, but having an app where the low-code platform you built-on makes it impossible to address some core user-experience fault is why I have a hard line against low-code in principle. Another example of this is this one particular low-code web-app platform (no names please) which hard-codes in some old version of jQuery which then precludes bringing in other client-side libraries or third-party widgets (think: stuff like ZenDesk chat support, and their widget's bad enough already).
So yes, it's cliche: but "it's a tradeoff" - but just be mindful of exactly what you're trading-away in exchange for developer productivity. You're either the kind of company that looks at, say, Blackboard and either sees them as a success for their large user-base - or you're someone who actually used it and consequently will carry that bad-taste-in-the-mouth over to not recommend purchasing it if they're ever put a position where they make decisions about what software/systems an org buys. My opinion is that the user-experience matters, and low-code tools make it easy to ruin the E2E UX if you're not careful.
And I can't believe this needs to be said, but yes it can be smart to hire programmers to build 5% of your system instead of 100%.
> Trying to be an entrepreneur in an area that you don't have experience in is a money pit.
Y Combinator exists as an explicit bet against this proposition. (They publicly said they wanted to find the youngest age where entrepreneurs could be successful.) To take another, AirBnB is a good counter-example. Should the founders have been experts in programming? Data science? Recommendations engines? Hospitality? If you erect enough artificial barriers, nobody will launch anything.
https://www.youtube.com/channel/UC4xKdmAXFh4ACyhpiQ_3qBw
I’m trying to be less judgey generally, but there were a few things in the one video I started to watch that had me giving some wild side-eye so I stopped watching and never went back.
What are you working on now?
Unity is not entirely no-code, but it comes incredibly close. I'm willing to bet there are a handful of iOS/Android games out there with barely a line or two of custom code written.
Without building in this way there is no way they would be growing at the rate they are - they would still be writing their MVP (they are now valued at >$100m in year 3, and are still supported entirely by spreadsheets as the investment in terms of focus is towards anything customer facing - they know they need to sort everything else out, it’s just everything has to be prioritised). Also their ops are still evolving so quickly that any investment in writing code to support ops is likely to slow down ops change (who need to be able to respond to issues nobody has seen before).
Any domain examples you can share where it's been successful?
If I need, say, authentication, why do I need to install a library and then read a bunch of documentation on how to use it? Why can't I simply plug it in (just like low-code!) and have it automatically work?
I think there is a lot of room to improve developer tooling and that the effort spent there would produce much greater rewards than developing a higher level abstraction, such as a pluggable authentication widget aimed at non-programmers.
Alternatively, tell me your complicated auth flows that will not have users running away screaming and are, therefor, bad ideas and should be replaced by cookie cutter stuff. Because that is where all of these things end up.
Drop in the plugin you want, configure the API keys, and then wire it into your User model. Then you can customize the urls, views, and emails.
You still have to read a fair amount of documentation and a lot of developers don't like the extra up-front work and reinvent the wheel because it's "simpler".
The simple use cases should just be plug and play. If you want a different solution: here are the tools, here is the documentation, have fun.
However, we're definitely not aiming it at non-programmers. I don't think completely general low/no-code solutions will ever take off. Everyone wants things far too custom, and at some point you won’t be able to beat the programming language of the time. Companies like retool are doing a great job in specific verticals — and I think it will always stay that way.
I think the next generation of dev-tools are going to be pretty impressive, especially with how easy and modular React components are — I’m bullish that React will become “low-code”
I'm over-simplifying of course, but these things sound simple until you ask all the "but-then" and "what-if". If someone actually makes them simple in a way that still lets me cover those cases I'll be the first to stop writing authN/authZ code.
AWS very much decoupled authentication from authorization with Cognito and it works very well.
I built the Castup[1] website using Webflow, use Outgrow for onboarding, Stripe for payments, Slack for communication. It’s a productized service startup in the podcasting space but I have enough knowledge of no-code tools to build a SaaS as well.
[1] https://useCastup.com
It was extraordinarily fast for static content, although forms and controls were a bit more difficult. We ended up building out some primitives using Stimulus and ActionView Components to make life easier, and overall it was a surprisingly nice workflow.
Would I recommend it to others? Possibly. It worked really well for our situation where time and agility were valued above all else, but I attribute the success there in part to the way the team worked and the fact that our founder was so proficient with it.
https://webflow.com/customers
https://bubble.io/showcase
And if you want to go back 20 years, here’s a link of sites built with Microsoft Frontpage :)
https://trends.builtwith.com/websitelist/Microsoft-Frontpage
What's important for me is that users can ramp up from drag 'n drop to coding by hand. Otherwise they might just end up feeling stuck with the tool.
I'd rather see users use and then discard our tool once they ramped up their skills, in favour of then just writing code using our tech. Much better than getting stuck forever in our competitors' rather limited toy editors. :)
Everything starts as low code, but complexity always creeps in. It's like Factorio, the code will grow.
The model is not perfect and does not work well for every type of process, but we have a few very satisfied customers. Just enough success to slowly grow our business and buy us enough free time to build and improve Lowdefy.
Currently it's working really well, like one gear turns the next. The apps we sell help us test and improve our low-code platform. The more apps we sell the more we invest in our platform and as a result all our apps get better, more feature rich and easier to maintain. Hopefully next, by building an open-source community around Lowdefy we can accelerate this cycle.
[0] - https://github.com/lowdefy/lowdefy
A visual editor is definitely on our roadmap. Our strategy is to make the schema easy to read, write and understand. We want to ensure the dev experience of working with the Lowdefy schema is first class so that change review and version control can be as productive as possible.
Adding a visual dev interface is resource intensive can easily distort the schema quality. We figured by first maturing the schema and making sure it works well with dev tooling, we can add a visual dev interface on top as Lowdefy becomes more popular.
I'm founder of a startup that develops DevOps tooling and we're debating how early to build out the ui. (We have the basics down with Vue like I mentioned.)
So then we really asked how lean can we make this platform to keep it agile while experimenting with the mechanics of the schema. After more than a year of that the experimentation paid off and we now have a very flexible, yet understandable schema for building apps.
But yes. Adding a visual editor on top is one of our goals - and we are getting closer and closer to making it happen.
Lots of opportunity with these tools and platforms!
[1] https://www.webase.com