Launch HN: Stacker (YC S20) – Create Apps from Airtable or Google Sheets
We've been working for ages on building something that lets non-technical people create software without code. We spent about 2 years building a really powerful and complicated drag-and-drop no-code app builder. It was really awesome, it could create social networks, SaaS, marketplaces – the works. The only problem was: nobody could use it unless they were already a developer! It turned out that even though you weren't technically writing any code… you were still actually programming, still thinking like a developer. Just with a really inefficient set of no-code tools.
We (eventually!) realised that non-devs were already building systems anyway; but instead of code they were using spreadsheets.
Spreadsheets are basically the world's most used database/IDE. They're great for modelling and managing data. But, if you've ever used someone else's sheet you'll know that they're not the best way to interact with the data. Giving someone access to your spreadsheet is pretty much like giving someone access to your SQL database – they won't understand it, they might see more than they should, and they might break the whole thing.
Stacker is basically an app layer on top of spreadsheet. We let you set up a nice UI, add user login, and limit who can see/do what using permissions. We also handle abstracting away the limitations of the APIs of Airtable/Google Sheets so that the whole thing stays performant.
The main two cases where people find Stacker useful are:
1. they want to create internal tools that are easier to use/understand
2. they want to allow customers/partners access to some of the data in their sheet without giving the whole thing
We've been really excited that most of our early users have been non-technical people who hadn't ever thought they could create software for their business. People have been creating marketplaces, CRMs, resources centres, order-tracking portals, ERPs… lots of stuff. We're a monthly SaaS model starting at $39pcm – we handle all the hosting, infrastructure, and even SSL certs etc.
Right now we support Airtable and Google Sheets, but we'd like to expand out to include other data sources like SQL databases, APIs and even MS Excel(!).
Underneath the hood we've got a bunch of technology from our original web app builder – a python backend that creates on-the-fly endpoints depending on the user's data model, and react frontend that can flexibly layout the app. Then on top of that, we've got a service that analyses the schema from your sheet and automatically creates your initial Stacker app.
I'd love to hear what use cases you can think of for this, either internal or external, and what you'd like to see it do in the future! Check it out here: https://stacker.app
p.s. History update – you might remember us from when we did a very early alpha launch as "Toga" a few months back (https://news.ycombinator.com/item?id=22746663). Thanks to everyone who helped us iron out all the bugs from that!
118 comments
[ 3.7 ms ] story [ 193 ms ] threadThe 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.)
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?
> Copy and paste text to another location, like a text document or a Google Doc.
Wow.
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).
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. :)
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?
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.
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."
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.
https://en.wikipedia.org/wiki/Stac_Electronics
Overall, though, we're pretty happy for the ecosystem of people creating their own apps is growing, and we're pretty sure we'll be able to offer some compelling benefits that PowerApps doesn't – and still stay on the right side of your security policies!
Best of luck
Stacker looks nice, but why is it better than the other options that have been around for a long time? At $349/app/mo (or $3480/app/yr) it seems more expensive than the others but perhaps the value is there.
We want to solve a much smaller set of problems really well – turning spreadsheets into Internal Apps and Customer Portals.
That means we've spent a bunch of time focussing on getting the things that everyone needs (User login, data security, lists, forms) really excellent so that you can build something really easily.
In fact, there's not really any "building", just "configuring" – you start with a working app as soon as you connect your data, and then customize it to look how you want.
Contrast that with tools like Bubble where you have to build out each screen, each form, the login page etc. manually.
(https://www.glideapps.com/)
Overall, we're used in a different way: Stacker let you make systems for your team to work from, or portals for your customers to self serve. We can be backed by either Google Sheets or Airtable, and we work on desktop and mobile.
We've got a real focus on creating something for daily use, and that gives you really fine-grained control of your business rules and data security.
Glide is, as you say, just GSheets, and just mobile. If you check out their examples, you'll see they're more focussed on small utility apps (e.g. Attendance Tracker) than larger systems.
https://solutions.appsheet.com/google-sheets-to-app
We've got login via SSO on the roadmap, both for social signon like Google Auth, and some of the more "enterprisey" options too!
How do you handle latency to google sheets or airtable APIs - these are not as responsive right ? Does it affect performance of stacker ?
And both of these fit that bill: the Gsheets API is generally quite sluggish, especially for large sheets, and the Airtable API only lets you fetch 100 records at a time, with no skipping pages!
We cache the responses from each API to keep reads as quick as they can be, and try our best to be smart for writes too.
For example I have a sheet where users can enter in thing on custom inputs and it loads data from an API Into the spreadsheet.
I would like to replicate this functionality in an app.
Also, if you've got Zapier attached to your Airtable/Sheet, then that'll still work fine too. People have done some pretty amazing things with the Zapier + Stacker + Airtable combo
Display stuff (charts, conditional formatting) etc. doesn't, although we are working on our equivalents to these.
This is such a huge huge need. And guess what? I am a software engineer. I just don’t want to mess around with coding if I don’t have to.
I think we need to see more about the interface for building an app and such. Bubble and others in your space or even Glide your direct competitor are better about explaining how the build process works.
IT groups like to rail against this, but they are also the ones setting up architecture review boards, CAB's and things like new activity committees, where good ideas go to die.
Ironically Excel is often the tool of choice, and it happened in an org I was in. A finance team had an Excel workbook they used to calculate payouts to different stakeholders of a set of oil properties. Over time this workbook grew bigger in scope and in data and was becoming unusable, so they came to our app dev org to rebuild it as a standalone application. In the process of rebuilding it, critical miscalculations and rounding errors were found in the workbook, and we owed years-old payments to some of the involved parties.
In a worst-case timeline, the team avoids having the problem solved by IT even longer, it culminates as a critical workflow issue (workbook becomes unusable to the point that the finance team cannot do their job at all and there is no quick solution), and the third parties realize they are owed money and sue.
So the big difference between us and Retool is who the users are and what for.
Retool is primarily bought by dev/product teams for building admin UIs on the side of their production DBs.
Most Stacker users are non-technical people in business roles, building operational tools on their spreadsheets. We've also got a much bigger focus on auth, login and making the experience work for external users.
We've not got much familiarity with using AppSheet, but I know a bunch of our customers moved to us from there. I believe they're pretty much mobile/tablet apps only.
If you can solve the former I would be grateful. Solving the latter is a much bigger challenge.
If you have any experience in your city, feel free to fill the spreadsheet[2]
[1] https://travelhustlers.co/cityfaq/
[2] http://docs.google.com/spreadsheets/d/1-Lut4zmeDw9z-ikRJPH1n...
for the baackend it's just few lines of python (flask) reading the spreadsheet api and displaying it
but as someone who change country or city every few years, it would save me so much time, money and hassle to know all those "basics"
https://docs.google.com/spreadsheets/d/1-Lut4zmeDw9z-ikRJPH1...
[1] https://azuqua.com
> Azuqua is no longer available for purchase. If you are an existing Azuqua customer looking for support, please email azuquasupport@okta.com.
- Even though I'm a dev, I find myself hating the maintenance of internal tools
- I looked through my GSuite and realize that I'm already using sheets to build micro apps. Each spreadsheet I create is a basic tool for collaborating around data. Adding a meta layer on top of it to enable things like permissions + better UI is a totally natural next step. I think there's a bit of an education piece to get spreadsheet users to realize that they're building micro apps, but once that aha moment happens, I think the value prop of stacker is really clear.
Excited to see where you all go :)
This is not necessarily a bad thing, there is still a problem here to solve. The approach is likely in who you market to and understanding who your market is. As much as you might think end-users are your market, they really aren't. Even if end-users are given the tools so they can design their own apps, a lot of them don't want to. They'd rather have IT do that for them. IT on the other hand, would love to have things that makes it easier for them to automate quick CRUD apps for all the internal business operations that have to be dealt with, especially at enterprise levels. This is why SalesForce and JIRA succeed and other too generic design your own database solutions targeted at end-users fail. As much as people love to hate SalesForce and JIRA for their enterprise-y ways they are making a lot of money doing what they're doing.
Bye bye boilerplate, until we meet again.
On that note, is there a business intelligence tool for the no-code (or low code) world that just works?
I want to visualise my database without having to type queries in terminal, and without using some clunky shit like metabase.
PowerBI is good too, as is Quicksight, and pretty cheap.
I think in the end there’s a nice balance that can exist. The more technical folks can set up the core data structures at the heart of a team, but anyone can add columns, create new filters or views.
Like an Airbnb for example?
What about Stripe integration?
Not a pre-defined set of logins.
The Airbnb/ecommerce usecase - where a logged in user "books" something would be simply awesome
https://github.com/ryxcommar/fullstackexcel
Here is our list of requirements:
- Providing a backoffice to our customers, where each user can connect to its own tenant and access its tenant's data only.
- The backoffice must be generated automatically from a data structure (db schema for instance)
- An API must be generated automatically from the data structure (allows to consume the data from web apps, mobiles, etc.)
- Ideally, this API would be a GraphQL server because that's what we use already.
- Advanced permissions and roles for internal users, basically need to configure who can view which tables, or has update/delete permissions on which tables. It must be flexible and non-blocking for our business evolution/future needs
- The backoffice needs to be flexible about UI components/views so that we can create our own workflows, views and components.
- Theming capabilities of the backoffice, per tenant, would nice to have.
- Also, my goal is to have as little to manage as possible, I'd prefer to use a managed cloud version over a custom "have-to-install-and-maintain" one if possible
I've tried many others, GraphCMS, Directus, Frappe, Django Jet, Strapi, and studied tons of other. Stacker is the only one who is flexible enough for our use case.
We’d like to support SQL databases in the future, which would give the option to go forward without starting from scratch.
5M cells is indeed a lot.
Having an exporter that could generate an SQL schema + API that replicates what the user's formulas did would be a cool feature, but probably very difficult. I could see building an 80% solution (for your internal use), then selling a consulting service to take your existing Stacker setup and turn it into a bespoke system built on top of a real DB. Presumably by the time the customer has enough records for that to make sense, they would have the money to pay for such a service.
Perhaps you could also offer an "archive your old data after $N years" feature. Maybe also sell snapshot storage, or allow the user to download the archive and save it themselves?
I don't know your tech stack or the business concerns in your space, but maybe that looks like generating a static site that bundles all the user's data, so it can later be viewed in a read-only format using a regular browser (allowing you to just scrape calculated formula values instead of having to implement the formulas yourself). I could see that being useful to a user wanting to pull up a record years down the line as it was displayed when it was created.