9
34 Comments

The fastest way to build small applications

Hey everyone,

Over the past months, my cofounder and I have been building a tool (called Gadget) designed to help developers go faster by removing/reducing all the boilerplate, repetitive non-sense we have to do as developers, and leaving us with the essential business logic to code.

Here's a demo [10 min], in which I build an appointment booking app end to end (in production, using Gadget): https://www.loom.com/share/75738fd721e6447d929ec3e9b8f7c0ea

Our target audience is developers who want to go really fast on:

  • side projects
  • freelance work
  • small applications built on top of major SAAS platforms

This demo doesn't capture everything but should give you a sense of how it would all work. The audience in IH is particularly relevant to our ambitions, so I'm curious if such a tool existed, would you use it? If yes, on what types of projects?

And some bonus questions for the keeners:

  • Would you ever pay for this? And if so, what's your preferred pricing model?
  • Does the fact that it's hosted/auto-scaled bother you or is that something you prefer?
  1. 1

    Interesting concept! Can definitely see it get used. I personally prefer to code and develop the backend of applications and utilize no-code/low-code frameworks for the front end (front end work can be just so obnoxious). Good luck!

  2. 1

    Wow, great work done! I love your video demo through Loom, Impressive! It is brilliant way to validate your idea. I am working on Tappy👈 as stand alone product but also considering building chrome extension as light-trial version of it. would your product work for that?

  3. 1

    For me the productivity deal breaker would be all the clicking. I'd want a 100% keyboard-driven mode with VIM support.

    Support for REST APIs would be a close 2nd.

    1. 1

      Thanks for the feedback. Rest is coming and we're trying to figure out all-keyboard navigation (outside of the state diagram which is always going to be a little "mouse-y".

      Would you be interested in giving it a twirl for 10-20 min to give me more feedback on the UI/UX of it? This whole "clickiness" debate has been something we've been thinking about internally, but you're the first "potential customer" to actually express the concern back to us.

      1. 1

        I have repetitive stress injuries and really can't justify 10-20 minutes on a mouse-driven interface unless there's a compelling need. Sorry.

  4. 1

    Impressive. Looks like quite a bit of work to get there.

    For me personally it would be no real option for anything remotely serious due to the fact that I cannot self-host and look at the code. And even if I'd just use it just for small customers, your business would reflect back on me.

    I think it could be an amazing open-source project where you could offer the paid hosting for. Absurd as it might sound, that would give me the peace of mind to go with a hosted version - at least for some customers.

    Question is also what the target audience is.

    No-code people? Or is this more like a Rails successor?

    1. 1

      Our current intent is to target developers, not because we think you need to write a lot of code to use Gadget, but that there's still a way of thinking that lends itself to writing scalable software (proper data modeling, reusing code, ...) that no-code tools and the no-code community aren't really great at educating users on.

      We think there's a lot to love in no-code, but until we get non-developers to think a certain way, apps built on no-code platforms feel like they are destined to hit a myriad of performance concerns as they scale. So Gadget is low-code for devs. You still need to think a certain way, but you don't need to write a ton of code for the same basic functionality that every application in the world just needs.

      It seems like your primary concern is trust and the lack of an escape hatch. This is definitely a challenge we need to overcome. Question to you:

      • Do you ever use Heroku or Firebase on a paid plan?

      The reason I ask is I believe that all developer productivity companies that are not open source face this same challenge and just need to survive and build enough of a reputation over time to convince the skeptics. Maybe you disagree?

      1. 2

        I certainly comes down to trust - but also dependencies (some might call it lock-in).

        I have used Heroku on a paid plan - but it has a low dependency and allows to easily switch to something else. Plus a good reputation.

        Firebase has a stronger dependency and Google has a bad reputation when it comes to longevity of services. Which is why I'd rather use AWS services.

        Now with your offering you have a very strong dependency. If there is something I don't like about your service I would have to start from scratch.

        For some very small projects this might be a risk worth taking for the speed gained - but this is a trade-off. And while I don't presume everyone sees it the same way - some will.

        I see two paths for this kind of platform. The wordpress path or the proprietary path. Which one will be the more successful - I don't know. But both can be.

        1. 1

          If there is something I don't like about your service I would have to start from scratch.

          Are you referring to a lack of libraries and dependency management in the "text editor" of Gadget? i.e. "if I hate your abstraction, can I still use my preferred tools on top of my preferred framework to custom code it?" The answer to that is yes though admittedly the demo does not address this at all. In fact, given all the feedback here, I think I need to reshoot the demo to highlight some of the developer concerns and how they are addressed (or not) in Gadget.

          1. 1

            No, I am not referring to libraries but I am talking about a lock-in. When your offering goes away, becomes too expensive, or whatever other reason - I cannot just run take it somewhere else. I have to re-build it in some other way. That's a lock-in. And by that you become a dependency. Whether that is a problem or not depends.

      2. 1

        Torsten has a good point! Even though the product is impressive, at the end of the day the main concern businesses have nowadays is that for privacy and peace of mind, i.e. "we control this server, we own the data, we feel safe". You will find clients for this SaaS, no doubt, but you will also probably miss out on about two-thirds of your potential client base - those who want to self-host it.

        I'm speaking from personal experience here. I have developed a similar backend solution and it has been open sourced from the start. Most of my clients want to host it themselves. Open source gets more traction which gets you more clients, eventually.

        One option is to sell hosting services and support for your open source backend. The other option is to sell a premium version with more features, also available for self-hosting.

        1. 1

          Interesting perspectives. I'd love to chat more and see your open source variation if you're up to connect and exchange notes?

  5. 1

    There's a lot to love here, but I'm still quite confused who the product is for. Unfortunately, you didn't actually show any of the code that would be used to wire up the parts you make easy, so it's hard to get a sense of what the real meat and potatoes of working with your tool would be. Building out the initial scaffolds is great, but then the actual work of building your core functionality begins, right?

    As a Rails developer, I can use a few of the standard go-to gems like Devise and Pagy to create a basic scaffold template with user management and paginated parent-child forms with validations and relationships in a few minutes. It's super impressive to someone who has never used a high-productivity tool before, but this is what you're competing with if your target demographic is truly "developers". Except that with a Rails app I now have an open-ended chassis and I'm not constrained by what you thought to implement in your UI, no matter how slick it is.

    I think that the path for a tool like this is to market it at people who don't think of themselves as developers. Specifically: this has more genuine utility to people who might today be tempted to use Microsoft Access. I know that sounds like dark humor, but given what you've created, I think that you'd be very foolish not to spend a few hours looking (again?) at Access and having your mind blown at how many parallels there are.

    To us developers, Access seems like this dinosaur (joke?) that won't die, but it's actually one of the most widely deployed software development platforms in history, and new projects start with it every day.

    1. 1

      Thanks for the feedback Leastbad. I think the UI challenge you allude to is very real. We're kinda hoping the acceleration offsets some of the reservations around the UI/UX.

      End to end, including deployment, how long do you think it would take to build the appointment app in Rails? I did the backend in Gadget in 10 min, and the frontend would probably take 2-3 hours. I feel like if I did this in Rails, even with all the bells and whistles of all the gems, I'm still looking at 3 days of work. So that's the acceleration we're talking about. And we're kinda hoping to find a excited base of users that value that, and slowly build our story to convince other developers over time.

      So the succinct answer to your question is:

      • in the early days: freelancers and agencies cause they build lots of apps, they want to build them as quickly as possible, and long term ownership and scaling of applications is actually something many/most do not want to handle so PAAS fits well.
      • later days: build the missing feature set to convince even the most hardcore of backend devs that they can infact build a bespoke app on Gadget, without losing control of the functionality, a lot faster.

      Wdyt?

      1. 3

        I watched the video, but I haven't had a chance to interact with the app. I feel like I got the gist of it but I'm definitely generalizing (with good intentions).

        My take on all of this is that the only thing anyone can do in 10 minutes on any dev tool is power through a script where they are intimately familiar with both the tool and every decision that has been made about how the app will be built. Heck, you really did yours in 3-4 minutes, if you edit out the explainations... but we both know that's not what development is actually like.

        I'd spend my 3-4/10 minutes running rails new, installing devise, installing pagy, and setting up associations. Of course, we've both "set the table" long before this, wrt seed data, some kind of theme, maybe some Heroku yak shaving. None of that is supposed to count against our clock. My point is... these "... in 10 minutes" videos are performative. We made a very popular one for StimulusReflex, so I get it. 😊

        I'm not a salesperson for Heroku, but it's genuinely hard to imagine an easier transition from dev -> live for an open-ended framework solution. Sure, you can say that even git push heroku master is too much for some people, but those people are not developers.

        The crossroads I believe that you're at is whether you want to reimplement VB6 in the browser and attempt to convince experienced devs that this style of of GUI-based app construction is just as open-ended as Rails/Phoenix/Django.

        Or, you can continue to build a viable Access equivalent and market it at people who don't see themselves as programmers, but need to build things remarkably similar to your appointment app.

        I suspect you can guess where I stand:

        • I'm not here to argue about what takes X days in platform Y; I am confident that you're productive in Gadget and I'm productive in Rails, it's the people we don't know that introduce all doubt

        • I truly don't believe that you can build a GUI that doesn't constrain your architectural possibilities, or else we'd all already be using them

        • I think you're smart to go after the Access users and foolish to try and convince experienced devs to switch to something less flexible with substantial platform lock-in

        I'd point to Airtable as proof of the above. Airtable demonstrates that there is a viable market in between Google Docs and Rails. Go take 10% of it and invite me to your yacht in a few years. Godspeed!

        1. 1

          This is fantastic feedback and reflective of a sentiment that's very real among developers. That said, we've explored the convo a few times and we think there's a way we can build this story over time (kinda why we start by focusing on freelancers that pick up small projects, not hardcore backend devs at companies).

          I truly don't believe that you can build a GUI that doesn't constrain your architectural possibilities, or else we'd all already be using them

          I do disagree with this statement though. To date, the hardest conversations at Gadget have not been about how we get feature x,y,z from Rails into our product but moreso how we survive long enough as a company to have the time and money to build those features. The hard problem seems to be surviving as a business for long enough to build out your complete vision. The product/technical stuff is very hard for sure, but so far, very doable.

          1. 1

            You have my full empathy on that front. I've been through it, thrice. Currently seeing how long I can survive without masters. :)

            Usually when I'm coaching founders who are trying to build an open-ended platform, I ask them "in your opinion, what is the most obvious thing someone would build using your tool?" and they almost always have an answer. Then I reply, "Put the platform play on hold and build that thing, first!"

            If you're right about the thing that needs to exist, why focus on the big scary unknown thing when you could nail a product execution - potentially learning a ton about what your platform needs along the way. After a year or two, not only are you further ahead without having to immediately take expensive investor cash to fuel your burn, but you now have a crown jewel application to show potential customers exactly what can be built with the platform.

            See, one of the biggest/saddest blind-spots most smart folks have around this part of customer development is that they chronically over-estimate the raw imagination and creativity of their desired demographic. You can hand them a tool that can do exactly what they need, but you're assuming they have the mental models to understand - much less describe - what they need. This is why consultants exist and charge such a premium; in theory, at least, they come in and just listen and observe so that they can tell their clients what their problem is and give them a path to solving it. The actual solving part is relatively easy.

            You're going to need some killer examples just to give people confidence that they are in the right place and give them permission to imagine that, just maybe, they could be the person that uses your stuff. So why not solve your cash flow by using your own tool to rapidly build some solid examples for the folks who need them?

  6. 1

    Wow, awesome! Looks promising. As a freelance web developer, i have moved to using headless CMSes and serverless functions to cut time setting up a lot of repetitive but essential backend stuff. I see this one as making it even more convenient for freelancers like me.

    Subscription more like netlify approach pricing.

    I prefer it being hosted.

    1. 1

      Thanks for the feedback! Freelancers are actually the ideal target in our early days. Any chance you'd be interested in a chat? I'd love to demo it further and ask you some questions, and offer you access to the tool in alpha (it's free, just collecting feedback)

      1. 1

        Sure. I will be glad to try it. Just email me where and when to chat.

  7. 1

    This is pretty cool! I love the visual workflow aspects that makes it easy to follow and hookup. I'm having a hard time understanding how it would hook up... I would want control of the UI and also the ability to add more complex logic that the tool might not cover. Maybe just for basic sites this works great! Super cool, anyhow!

    1. 1

      Thanks for the feedback! The idea for this early alpha is that Gadget is a backend builder (data models, crud and custom API, business logic, Admin views) and that you use the API (or JS client) to build the frontend you want. The UI you see me building is the "Admin views" for the internal staff.

      The product is in an open alpha if you're up to try it out. We'd love the feedback.

  8. 1

    This is really impressive! I'm not the target for this service but I can see how it would be worthwhile to developers.
    FWIW, I like that it's hosted and scales automatically. I think for people building simple apps that is a great option. Just thinking out loud, I think SMBs would be a good target auidence for this. I used to work in the dental IT field and I can see an office using that to do staff management but also patient management. Unfortunately, practice management software still don't make it easy to integrate with their DBs.
    Unfortunately, SMBs, at least dentists, tend to be very cheap in where they'll put their money.

    1. 1

      Thanks for the feedback Kamal. I'm curious why you aren't the target or perceive that you're not the target? Any insights you can offer will help us refine our go-to-market. Thanks.

      1. 1

        I'm investing in learning to code myself and enjoy it. Not so say I wouldn't be in the future. :)

        1. 1

          That makes sense. I'm a big fan of learning the fundamentals the proper way, before using the cheat codes to go fast!

  9. 2

    This comment was deleted 8 months ago.

    1. 1

      Thanks for the mentioned of Nhost <3 (I'm the founder).

      I just wanted to add that we not only provide Authentication but also: Storage, Serverless Functions, a CLI for local development and a GitHub integration for you to deploy your backend the same way as you deploy your Jamstack frontend (think Netlify / Vercel).

      Happy to see more BaaS alternatives to improve the productivity for developers and businesses.

      1. 1

        NHost looks real cool. Feels like it's heavily reliant on Hasura under the hood. Was this built before Hasura Cloud? There are a few things that seem odd about Hasura's mental model of the world imo. In their worldview, the database sits at the center of the "backend" (or arguably is almost the entire backend) and things like validations and actions just dangle off the database which makes setup way harder than it needs to be imo. Enforcing validations on Hasura seems like a nightmare.

        And little things like how they implemented upserts. An upsert in Hasura is not treated as a single transaction which seems insane to me but people are using it so maybe I'm wrong.

        Curious, does the NHOST "shell/boilerplate" address some of the Hasura shortcomings?

        1. 1

          Yes Nhost is very cool!

          It was released before Hasura Cloud but we serve different customers.

          At Nhost we focus on productivity for developers who wants to build apps faster with a modern and open stack. Much like the backend alternative to Netlify / Vercel.

          Regarding validation there are many options with Hasura. You can use the permission system. You can use the CHECK-system. You can do async post processing via Event Triggers. Or you can use Hasura Actions to write custom validations in any language.

          For me those options are enough.

          When was the last time you had a "nightmare" with validations with Hasura? And what was the validation problem? Would like to know more about it.

          Regarding upserts not being transactional where did you get that information? Would like to learn more about it that too.

          1. 1

            Ya, so lemme zoom in on validation specifically (re upsert, I've hear it anecdotally from three devs I trust)

            1- Their first answer is do it with CHECK constraints:
            At any reasonable scale, check constraints slowly become a growing burden on your database. IMO you always do validations in code. By the time you get to the database, it should be a simple insert.

            Backend languages like Rails built facilities for this expressly to move people away from Check constraints cause they will snowball into a nightmare as the app scales in usage and complexity.

            2- Their second answer is to do it with PostGres Triggers:
            It's a validation at the db level so same issues as #1 re scaling (in fact heavier than #1 because this validation can do more complex stuff) But beyond that, you now need to learn plsql (pretty old and arcane) and start writing your complex validations without any libraries or packages or any of the niceties of coding in something that is not plsql.

            3- Hasura Actions: Finally a validation solution not at the db level. Except, their implementation kinda defeats the purpose of Hasura imo cause now I gotta go spin up my own serverless function somewhere and I guess Hasura Action is simply you calling that function to run. Suddenly you went from only needing Hasura to Hasura + Lambda just because you wanted to build performant validations outside the DB.

            4- The permissions solution seems like a hack, even by their own description when I read their docs. I can see it working for select validations, but not many/most.

            Honestly, I like a lot about Hasura, but their validation stuff always struck me as lazy. Instead of building a solution within their product, they punted to PostGres and serverless functions, creating more work for the developer.

            1. 1

              But when was the last time you had a "nightmare" with validations with Hasura? And what was the validation problem?

              1. 1

                The nightmare was me mostly figuring out which option to use, when, and then learning about plsql for the first time and having an immediate allergic reaction to it because it's like stepping back in time compared to Rails. I don't think Hasura Actions existed back then.

                Of the four solutions, the only one that seems correct to me from a long-term scale standpoint is Hasura Actions (validations in code, not at the db). But Hasura Actions is basically Hasura telling you to go figure out your validation somewhere else, and then come back and tell Hasura where it is so that they can trigger it.

                I don't really know how the Nhost wrapper is interacting with Hasura, but maybe it's possible for you to solve some of these pain points.

                1. 1

                  Ye we provide serverless functions so it's easy to create webhooks for Hasura Actions and Hasura Event Triggers.

                  The learning curve could be improved. Hasura just got popular (20k GitHub stars) in the last 2 years so lots of best practices to still to be explored.

    2. 0

      @meoweloper
      Ya, I have different thoughts on Hasura (some shared below). Supabase is definitely more interesting IMO.

      We already have the js client. It's a pretty rich urql client with Typescript type support for your types and a few more bells and whistles. If you're up for it, I'd love it if you gave Gadget a twirl and offered some feedback. It's not ready to be used for production use-cases (still in a very private alpha) but we're looking for feedback from devs on whether the whole experience feels rich and ergonomic enough (specially given that there's a GUI that might not appeal to developers at first glance)

      1. 1

        This comment was deleted 8 months ago.

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 47 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 27 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments How I Launched FrontendEase 13 comments