Quickbase, for example, was recently sold for $1bn, and is one of the category leaders, with revenue over $100m. Their whole model is no-code business process development. For some reason, Valley types never mention Quickbase in the market, and only think Airtable et al created it, even though QB is the behemoth.
Airtable (and Stacker) at least let you build for free, then upgrade to monthly accounts at launch.
Not affiliated with any of them.
People seem to be able to design systems pretty well using just Airtable or Google Sheets – they're just lacking some pretty important abilities (UI, logins, security) to make them work the way they want.
Both me and my cofounder come from the Salesforce ecosystem, where they've done some of that really well, and some of that really badly.
I agree, all of these things are a prerequisite to be able to truly scale across an org, and we're definitely not there yet, but it's firmly in our sights.
Can I do all this with Stacker? Merely using a couple of Google Sheets as my back-end DB?
Seems paradoxical but it's not. Belief empowers, without that you think, I might break it, and that will be terrible. You can't break a spreadsheet.
Spreadsheets can absolutely get broken
Giving people access to your sheet can be like giving them access to your SQL database.
My point is people don't want the responsibility us devs have to build "apps" that they are afraid they will make broken.
I think we probably don't need no code tools to help people build "apps" we need a more expressive executable document the combine stuff from the web, Microsoft word documents and Excel into something that's a little more powerful and fits today's use cases.
Just my two cents. Feel free to try to crucify me cuz my views differ to yours.
Are we not talking about the psychology of day-to-day users, where they are afraid to tinker too much?
That’s the impression I got when you said “Belief empowers, without that you think, I might break it, and that will be terrible.”
If that’s the case, then I stand by my comment as I’ve seen first-hand the hesitation people have about accidentally breaking a mission-critical spreadsheet.
Now, let’s be clear: I have not said anything about “no code”, as to me there are a lot of compelling arguments both ways in this thread. I am saying that “Excel” is not unbreakable nor does it free the user from fears about breaking something important (from a business perspective, breaking a vital xls document and breaking the Excel application itself are functionally equivalent, even though you and I know that Excel the program can be fixed essentially trivially by the right person with the right tools)
If I hadn't been so triggered by being unresolved about being criticized as a kid...I probably would have seen that what you're saying just backs up what I said: if people are scared of complex sheets, they're likely terrified of app makers.
I wish people like you would acknowledge the good points I make, and not take them out of context, and not define themselves by disagreement, but say something like, "Well you can break a spreadsheet. But I get what you're saying, it's less scary than apps in general."
And I wish I could not get triggered and just respond like: "Yes you can break a spreadsheet. But they're still way safer than app makers. Which is what I mean."
And I wish HN was not such a fucking shit show of people acting out and abusing and being mean to each other...but then why do I keep coming back?
But I'm not the boss of HN and I'm not the boss of you. So all I can do is fix my own reactions. People like you gonna keep existing...finding disagreements, maybe you enjoy it...maybe you're unresolved about something and this is how maladaptively try to recapture your power.
Whatever it is, we're all fucked up. We all just gotta find our own way that's to live that's free and untormented by past traumas that we didn't deserve and that are not our fault.
Maybe that's why I keep coming back...because it pushes my buttons, and I know that's some opportunity...it gives me a chance to work it out...rather than just "act out" on automatic. :)
True client story: I was once required to fill out opex/capex split timesheets into an Excel spreadsheet once a month, for each of my teams.
The spreadsheet came with instructions containing dire warnings that changing the formatting would change the semantic meaning of some of the cells, thereby breaking the spreadsheet for everyone.
I'm pretty sure that the developers of that spreadsheet used cell formatting to encode metadata about the cell values.
Freedom = more ways it can fuck up. Which is more scary.
We don't need "easy to use". Easy to use just means "easy to make a big mess."
It probably needs to be hard to fuck up, less magic, not too expressive, but targeted on the problem. Constrain people, and they will still find a way.
I think making things easy to use has been over-hyped by idiot founders and investors who don't get the customers they pretend to understand. But yeah, reject me from YC 9 times, and don't fund my work...I guess being an indie dev/maker is more my style. Who wants to have an investor boss anyway?
One is: have a good intuition/model for what will need to be changed. (What will need to be changed and what effect that might have).
Another is: confidence that he'll be able to resolve any problem he might get into.
(That's not even considering that programming, I think, gets an aura of nerdy/hard, when a lot of it is very accessible).
> Copy and paste text to another location, like a text document or a Google Doc.
Wow.
This can be mitigated, as if Stacker offer the top 5 a massive licence discount compared to big enterprisey tools, so they're making more profit on the same result, then they'll pick it. And for the big enterprisey solutions that are built in an old, expensive way, they won't be able to compete on price for long, which could be interesting.
Not to be overly cynical, but part of the appeal of a large expensive system that "everyone" uses is that you feel better writing that large check. "Nobody gets fired for hiring IBM."
The reasons for this may be:
1. Even when the coding is free, the problem understanding part is not
2. The amount of work to be done to implement a new process or system is non-trivial, but temporary, so you need temporary help.
3. Probably another 3-5 reasons I haven't thought of.
In any case, it seems you would have to pitch your solution to a consulting firm. If you get one of the top 5, you're golden. However, they might prefer the real expensive enterprisy solutions. You're better of pitching to larger but lightweight organizations.
One way to do that is have training around learning typical client processes, typical solutions, and how to implement them. Or how to recognize issues. (Making this up: look at the balance sheet, if inventory is building up, turnover is low. You want a process to push back the order time and link it to sales.)