Would love to get your feedback if you do try us: https://reflect.run/

I can point to this video to say, "this is what I'm doing when I'm writing tests", and I think at least some of them will understand the value proposition. The more savvy ones might buy into your platform or even try constructing tests themselves. Bravo!

Maybe it makes sense for some, and if people pay you for it then that’s great, but to me I cannot see the economics of that ever working out.

Usually when folks are considering us, they're comparing us to the other alternatives which generally are either (1) have folks on staff do each regression test pass manually, (2) hire additional devs/automation engineers to build a code-based automation suite, or (3) have existing developers spend part of their time building and maintaining a code-based automation suite. When you look at the cost of those alternatives we tend to be pretty competitive.

Where we're not a good fit pricing-wise is when someone wants to run very simple tests at a high volume, like running synthetic testing / monitoring scenarios in production, or for load testing.

I guess there is a happy point in between too small and too large where you have a bunch of QA, but no dedicated people to keep your pipeline up (and if things like Cypress didn’t exist, it’d be more or less impossible).

That said, if you think that unit tests are always required, then I think that you are a victim of code complexity. Let me explain. I do believe that unit testing is good to master complexity, which often becomes out of hands with classical approches because the code is complex by itself (new lib versions popping up all the time, breaking refactoring). The thing with low-code is that it lowers that complexity by proposing more declarative approaches, which are more stable and less broken when changing versions (think of a static web page for instance, you don't really need to test it that bad although the browsers versions bump all the time).

I think that it is more important to be able to control complexity in order to avoid testing, rather than having to test "no matter what", like your reaction suggests. Plus, testing implies CI/CD and a lot of automation that are extremely complex to set up and consume a lot of resources.

I wrote a blog post about this stand-point lately https://cincheo.com/2021/10/03/when-low-code-meets-local-fir...

DISCLAIMER: I am currently working on a new low-code platform for frontend development based on the local-first paradigm. (web site: https://www.dlite.io, platform, with examples: https://plaform.dlite.io).

> I think that it is more important to be able to control complexity in order to avoid testing,

I think that's a worthy ideal to strive for, but it's not so easy to control complexity in practice.

First, a lot of complexity arises from business logic requirements. Even if you have an "engineering" department, they're going to have limited ability to negotiate away complexity in business concerns. And many outfits who adopt No Code don't have engineering departments, and aren't well versed in engineering principles like simplifying, testing, or even keeping backups, let alone modularization, separation of concerns, loose coupling, or other approaches for managing complexity at scale.

And then there's time. It takes time to whittle something down so that it is simple and elegant. That time costs precious resources which small outfits may not be able to spare.

You are aware that there is such a thing as a Pontiac and such a thing as a Mercedes, right? One is better than the other. Costs more, too. That doesn’t mean there isn’t a place for both to exist. That doesn’t mean the lesser one is trying to be the more expensive one and failing.

You are arguing against a straw man, as I don't assume either of those things. Testing a magic bullet? Ludicrous.

> You are aware that there is such a thing as a Pontiac and such a thing as a Mercedes, right?

Hmm, but both a Pontiac and a Mercedes present the same driving interface.

I would instead compare No Code to DIY tools for (pick your industry: music production, graphic design, etc). I agree that you can go very far and do amazing things with DIY.

I'd say that's a given, both that they're not very complex and not intended to scale past a few users.

> tend to fall apart as they become successful.

There are lots of definitions of success. A dashboard on a phone app so that the boss can see the green lights on his servers is successful. It gave him what he wanted: green lights on his phone.

> By and large the target market for No Code doesn't value testing.

This seems to be your qualifier of why they aren't 'good'. I don't own one, or work for one, or even subscribe to a platform that makes them, I'm just a passer-by here, but I can see the value in them. The only one I have used is open source (NodeRed).

When there's no time and you need to glue two or three API's together in 30 minutes, I see nothing wrong with them. It goes without saying that the result will be fragile and only for a handful of people, probably only one of which will get write access.

Here's my use case: co-founded a disaster relief non-profit in 2017 (hurricanes). Our window of opportunity to do good deeds was about 3-4 days, by then the red cross and fema trucks would arrive. When we need to process data it's probably a job with a roughly $0.00 budget and needs to be done in 30-45 minutes, then there's something else to do.

For that? They are wonderful. I built a phone bar-code scanner that could pull price data from Kroger's API to account for food donations in about an hour and a half. Can anyone else do that writing code by hand? I say no, the UI alone would take longer (however rudimentary that UI is). Was it tested? Yeah, a quick manual once-over and me face-to-face telling the person admining it that if the bar code didn't read just google it and plug the price in by hand, or don't and we'll do it later if that isn't feasible due to volume. We were just trying to do a slightly better job than a pencil and a clipboard could do, not a perfect one.