>> I have wasted a significant chunk of my life counting out small numbers of parts into bags and posting them to people.
So, small parts like this are always counted by weight, and I'm wondering why you would spend so much time on a counting solution when "buy a scale" is right there.
He's counting out like 6 at a time. He needs a fast way to pick small quantities precisely, not a fast way to check large quantities. Once they're picked they're easily verified by eye.
In volume, small parts are dispensed by carefully designed machines, and then the result is counted by weight. You still need control of the dispensing, and as he's putting in small numbers of items the counting is the easy bit.
He needs 6 screws at a time, and the goal is to save time compared to counting manually. I'd guess that 7 would probably be fine occasionally -- maybe even 8 from time to time if the process is fast enough. I'd further guess that 9 screws is a non-starter (screws are inexpensive, but 9 represents 50% waste, which is quite a lot).
The lower limit is hard-set at 6 because the kits that he's producing and selling require exactly 6 of these screws for end-user assembly.
A small cup that would reliably scoop out at least 6 screws and no more than 7 or 8 screws sounds like a simple and elegant concept.
What does this cup look like? Is it faster to use this cup than counting by hand is? (Is it faster than the reproducible screw counter that he's already built?)
Up to roughly 100 bills it's pretty much bang on - even with a cheap $10 scale (American Weigh Scales Digital Pocket Scale has a bunch of different options). Each bill weights roughly 1 gram. So - accurate to within 1% - and presumably the banks have better scales.
I suspect at scale (moving either a lot of batches or large batches), you also need to take variance into account more. Some bills might be dirty or have stuff stuck to them, some bills might be damaged and have bits missing? And other things that occur in practice that I can't think of from the comfort of my armchair in 30s.
I’m building an app that facilitates discovery and eases payments for roadside stands that sell produce, honey, maple syrup, eggs, firewood, crafts, etc. The concept is that any roadside vendor can sign up for free (forever, no add-ons or upsells) and they have an online home for their home business. The vendor can list up to 3 stands and show off the products they sell in each stand. Users can discover stands near them by list, search, or map, view the vendor and stand details, ratings, payment methods accepted, etc. When arriving at a stand the user can scan a QR code which opens a web cart, allowing them to add products they are going to purchase and then “check out” using one of the vendor’s stated payment methods like Venmo, CashApp, PayPal, Apple Cash, Zelle, or good old hard currency. We make these payments easier by standardizing the check out experience but we do not facilitate payments at all - these stands have always been and will continue to be self-serve on the honor system. Once you’ve paid, you get a receipt and take your goods. The vendor gets an alert that a sale intent was started and by which method so they know where to look for their revenue. In the future we may help with some basic reporting and very light inventory management if vendors ask for it. We allow users to alert the vendor if a stand is out of stock, which is also reflected in search so other users are informed as well. Users can then ask to receive re-stock alerts as the vendor restocks.
Then of course users can favorite stands and products, share them, rate them, and create shareable collections of stands they curate (The Honey Trail or Summer Sweet Corn All-Stars, etc.). Eventually we will be adapted for events like farmer’s markets, craft fairs, and christmas markets.
I built this because I am a maple syrup producer (tapping starts in a few short weeks from now) and I’m starting to get into mass sales of my syrup. I felt like people who produce and sell these products put a lot of hard work into the process and deserve a legit discovery tool as well as a basic stand management system that does not make them change their process or get in their way. An app like this costs basically nothing to run and I will ensure it is free to use as long as I am in charge. I’m testing this week and likely soft-launching in the next couple weeks - the goal is to be online around March 1.
It was just going to be web-only (Supabase with a Svelte front end) but after Claude put me in timeout last week I tried Antigravity and now have 80% of an iOS app and will scaffold my Android app in the next month - so native apps will follow a web release pretty quickly.
It's easy to see the word Waymo and think clanker autonomous car, but there are very often people inside that car - they are a rideshare service after all. Calling endangering other humans "legitimate" because you dislike the taxi company is not a good look.
lol same. Hilarious when this shit goes down that we all rely on like running water. I'm assuming GitHub was hacked by the NSA because someone uploaded "the UFO files" or sth.
I'm just getting started in iOS development as a hobby, but what does this mean? Can I now build my app in Xcode with an Android target and use that binary in the Play Store? It surely can't be that easy now is it?
> Can I now build my app in Xcode with an Android target and use that binary in the Play Store?
No. The vision document[1] lays out the direction of travel. Currently the focus is on shared business logic and libraries, rather than full native applications (although that's certainly a goal, albeit a very long term one).
The SDK doesn't quite work that way, your iOS-specific dependencies like SwiftUI and UIKit aren't available. For SwiftUI development, [Skip](https://skip.tools/) has a transpiler that translates your SwiftUI code into Jetpack Compose.
Without Skip, you can still share other code through JNI - similar to Kotlin Multiplatform.
Not yet, and possibly not ever quite from Xcode. But using Swift CLI tools, yes.
The example Activty I saw is pretty rough ergonomically, but I have no doubt an ergonomic, SwiftUI-like library could be built on top of what’s currently there and/or on the roadmap.
I built https://invoicepad.app which is a free, completely in-browser tool for creating invoices, estimates, and quotes. Yes, similar apps have been posted here before, but none were built the way I envisioned, so I made my own. The key difference: all invoice data is stored in the URL hash, not the querystring. This is important because querystrings are sent to the server with every request, while hashes stay local to your browser. This means I can never see your invoice data, unlike other similar apps. The workflow is simple: use your browser's bookmark manager as your invoice filing system. Or if you want to keep it offline, just copy and paste invoice URLs into a text document for storage. I’ve also included helpful features like saved profiles to save on repeated data input. The next step is to finish working on a browser extension (v1 is being tested) to make bookmarking, editing, and saving changes even easier, that is if I ever stop being distracted by other side projects.
I recently moved two sites from GoDaddy's predatory WordPress offering (they were charging $1k a year just for some security add-on) to use Hugo + DecapCMS + AWS Amplify. Decap is a fantastic "good enough" CMS to do anything clients of this size need, the only downside is it takes about 1 minute to deploy any changes. Amplify let's you lock a version of Hugo to use, or bring your own, and it will build and deploy your site on any new commit if your repo is in Github or Gitlab. Both clients are currently billed $0.51 per month, and the only reason it is that high is because Route53 costs $0.50 per month per hosted zone. So both these clients went from paying nearly $3k each year for a WordPress site to paying just over $6 a year for a site with nearly the same functionality and none of the maintenance or security concerns. And once everything is all set up, which honestly is not that hard, the only "tech" they need to know is how to sign into Gitlab, which are the credentials they use to log into their Decap admin.
I mean, yes, that sort of setup is less fragile than someone's clobbered-together homebrewed site, but it still requires a dev to maintain. What happens to your client's site if you or they can't maintain the dev-client relationship anymore, for any reason? They'd have to find another dev willing to take over that setup from you.
That sort of thing sounds great for an agency managing multiple sites running off the same template and framework, but for freelancers, it's still too bespoke to be easily portable between clients, hosts, and other freelancers. If someone came to me with a stack like that (and they have), I'd offer to help them migrate it to a more standard setup like Wordpress or Wix for a one-time cost, after which they would pay the vendor directly. But otherwise I wouldn't want to be responsible for maintaining it, especially for just one or two clients.
It's just way too much setup and maintenance. The AWS setup time would itself cost (in dev hours) a month or two's worth of hosting, and Hugo updates or DecapCMS changes would take even more time. Even if the costs to me were $6 a year, the dev hours required to keep a site like that going would far surpass what it would cost them to just pay $20 a month for a vendor-hosted + managed system.
It also introduces multiple points of failure, and if I were hit by a bus or something went wrong while I was on vacation, they'd have no idea if they need to talk to their web host, their CDN, AWS, DecapCMS, Github, or me... they probably don't need to talk to me at all (nothing I can do about any of those services if they have an outage), but they will have no support outside of me.
I don't have anything against self-hosted setups like that for the right audience — I have many such ones myself — but I think they're way more trouble than they're worth for clients who aren't already web-savvy.
I work for another headless CMS (not Decap) and I frequently have to try to help customers who inherited an old site from another agency who didn't properly explain what a headless system is, and they get really frustrated because they end up having to pay a few hundred dollars to a third-party dev just to add a new article category or whatever. It's the kind of thing that would take them ten minutes on Wix/Squarespace/Wordpress, but requires a dev for a stack like you're recommending, and it'd take anywhere from a few minutes (if it's a common stack, like Next/Astro + Vercel) to several hours/days (anything more than 2-3 years old, especially). That will far, far exceed the time and money it takes to host for several years on any of the standard consumer platforms.
For some of these sites, even the original developer who first made them for the first owner didn't want to take them on again — they knew how much work it would be to update them to a usable state again (but that's usually more Gatsby than Hugo).
I'd be very, very wary of recommending such a stack to anyone who is not working with an agency or is already themselves a developer.
Yeah but then I have to figure out the pocketbase API and keep it as a dependency. I'd rather the dependency footprint be as small as possible, accepting the minor tradeoff of having to implement auth myself.
Supabase for registration and auth, frontend framework of your choice for views, Stripe payment links for subscriptions. You'll have to sprinkle in some Supabase Edge Functions for Stripe webhooks for your entitlements flow as well. AWS SES for transactional email. Something like Basedash for your admin panel and at this point you're running an MVP at least.
