Show HN: Buildman.io – Cut your development build time instantly | Hacker News Reader

Show HN: Buildman.io – Cut your development build time instantly

buildman.io

9 pointsa13i10 comments

Hey - Thanks for sharing! I think projects in this space are really interesting. Especially if covid and crypto continue to make fast compute expensive and difficult to get.

Mightyapp is one you might be familiar with for browsers.

I don't write much for Android (yet, I'll keep this in mind if I do wind up writing more). What I would be interested in is a version that does the same thing for rendering in Unreal Engine. I believe unreal already has the protocols for distributed rendering but the cloud services that do it look sketchier than this.

One tip, I noticed in the pricing in a few spots it says "ultimate" I believe you may have meant "unlimited" there.

Good luck with this!

Hi, Thanks for the feedback and the tip. Yes, I am familiar with mighty. I think it will be huge. I'll check Unreal engine and maybe other game engines, but we focus on Android because it sucks.

Hi everyone Buildman is an Android Studio plugin to build your codes in the cloud. If you are an Android developer, you know the CPU fan sounds like aircraft when you hit the run button. But with Buildman your code gets built in the cloud and no CPU/memory is used on your side.

Feedbacks are welcome

why would I pay for builds when its free to use my cpu? any company worth somthing is going to give you a decent machine. if you don't have a decent machine you wouldn't have the $$ to pay for remote builds. I could see a use case for very large projects.

Thank you for your feedback. There are two main benefits: 1. Your resources(especially memory) are free for using other apps like Figma, Emulator, etc. Also, during the build, your machine is workable. 2. Faster build: Because we build the codes continuously in the background, next build will be much faster. Regular Android projects take minutes to build with Buildman will take seconds.

I think you're grabbing at straws this with this project, and your "pain points" kinda state that right away.

Less fan noise?? Do I really hate my fan that much? Can I even hear it through my earphones? Do/will M1 Macs and next gen ARM Windows/linux even need a fan?

Save battery? How many people are regularly coding their android apps without being plugged in at a desk? Maybe you know more than me, but I almost never code when I'm not plugged in, and I don't think I've ever bundled on battery. Not that I couldn't, I just have no need to. Again, battery is becoming a non-issue for many of us.

I think there is some serious flaws in your logic around "time saved".

If you save 30 seconds on every build (30% more than you're stating), what's the time to upload my code to you, and the overhead in doing that? Then what happens when the build is done? I download the APK? What's the time that takes? Have I saved 30 seconds at all?

If you're saving me 30 seconds 20 times a day, are there not other things I could be doing for those 30 seconds while my computer is building?

So, I can pay you to do something that I can do in 30 seconds, and that I do 20 times a day, or I can not pay you, and just do it myself, for free.

Now lets take the best case scenario. I can make each employee 10 minutes more effective per day. Is that correct? But am I actually going to be able to measure what they are doing for that extra 10 minutes? Am I REALLY going to get 10 minutes more engineering time? If so, that's $10/day per employee. I'm paying this person $100/hour, do you think I'm micro-managing down to the point where I'm saving $10/day. This is also assuming that I'm paying the person $200k.

You've taken a very top down approach in your maths, but you need to also go bottom up.

Having said all of that, I'll tell you from my experience, we don't build 20 times a day. We run dev devices via USB (we're React Native), and maybe bundle a few times a week at most.

So, now add into your math, how many companies are bundling their app more than a few times per week? How big of a market opportunity is this?

So, yeah, you haven't convinced me, I'm not a believer.

HOWEVER, do I believe there is an opportunity for a great dev tool to improve development experience? Yes, there is. Do I know what that is? No, I can't help you there. But when you find that real need, you've got a great domain name, so that's a start. :)

I don’t know much about the Android build process but I think I’d pay $20/m if something can get my .Net build down from 20s to 1s for much quicker change/retry cycle but whether that is technically possible in the cloud on demand with startup latency etc. is another question. Whatever the magic is happening in the cloud just do that thing on my machine!

Such great feedback. Thanks!

The main advantages are speed and freeing CPU/Memory rather than battery and fan noise.

There is no overhead for downloading and uploading, thanks to binary diff.

The building process for Reactive native and Android Java/Kotlin is different, In Android, Gradle compiles code\xmls almost every time you hit the run(instant run and apply changes does not work well).

Happy to know you liked the domain name :)

Then I'd say focus on the speed, and drop any references to these "problems" that don't really exist.

So, I still don't know how much pain your customer is in. You've said "yeah, not a problem for React Native", but there are other environments that people develop in too. What about Flutter? Etc etc.

So I'd say be clear about what dev environments you help with.

You say "fast" and then describe the hardware. That's not the way you want to pose that. I had to look at what my machine is...2GHZ & 16gb Ram.

What you want to describe is how much pain your user is currently in, and how much you can help them.

You do say "Save 20 seconds", and that's good, but is it 20 seconds on a 40 second build? Or on a 5 minute build. How painful is that 20 seconds. If it's saving you 50% of the time on a build, that's good. If it's 5%, probably not so good. And still, it's 20 seconds! If it was 20 seconds on an auto-refresh type situation, yeah, that's annoying. If it's 20 seconds like a test runner, might not be as big of an issue.

Can you frame this in such a way that even somebody who doesn't build using Java/Kotlin can understand the pain you're solving? Can you make somebody who doesn't have the problem want the solution anyway?

As I alluded to in my first comment, saving 20 seconds might be helpful, but it needs to be helpful enough to overcome the inertia and familiarity of continuing to do what I already do.

Hope that helps.

It helps a lot. Valid points. Thanks.

Reply on news.ycombinator.com