Gymlocity (https://gymlocity.com) - All-in-one gym management platform for small gym owners.
Building this for personal trainers with home gyms and small 1-2 location owner-operated facilities. The big players (Mindbody, etc.) are overkill and expensive for this market.
Core features: class scheduling, member booking, Stripe payments, and workout programming (the part most gym software ignores - trainers still use spreadsheets or generic apps).
Stack: React 19 + Vite frontend, ASP.NET Core 10 API, PostgreSQL, multi-tenant architecture so each gym gets their own branded experience.
Currently polishing the member dashboard and workout tracking UI. The goal is something a solo trainer can set up in an afternoon without needing to call sales or sit through demos.
Another to add to the list:
Allow flexible naming. For example, drilling the two sum problem requires the user name the hashmap prev_map, but I feel memorizing this sort of stuff detracts from the lesson.
Good point, and that matches other feedback I am seeing.
You are right that in the current version the checker is still too literal about names and structure. In two sum for example it nudges you toward my map name instead of letting you use your own, which is not what I want to optimise for once you already know the idea.
The plan from here is to keep an editorial mode for people who want to follow the exact solution and add a more flexible mode that accepts your own names and structure as long as it is doing the same job. Over time the checker should recognise what you actually wrote and adapt its objectives and feedback to that, instead of forcing everyone into one naming scheme.
In a cold climate, I would expect burying it to use the ground as a natural insulator. Why was an above ground design chosen?
Specifically, does the need for heavy insulation and the active heating of the sand make the ground a less effective or even problematic insulator? Could excavating and building a below-ground foundation for a high-temperature device like this be more complex and expensive than an above-ground silo? How would permafrost conditions affect this design?
Because digging is expensive and there's plenty of land. More efficient to use the budget to build a bigger structure than to build a smaller one and dig down. Bigger structure also gives you better insulation (surface area compared to volume decreases non-linearly with increased volume).
It seems that this is directional, flowing from Android to Apple but not necessarily back (e.g., me airdropping a photo to my parent who uses Android). I'd love for this to work in the other direction as well.
There's a gif on the blog showing file sharing in both directions. Apparently "Contacts only" sharing doesn't work yet, as mentioned in another comment: https://news.ycombinator.com/item?id=45995586
I’m building https://www.kidcarekit.com, a Rails SaaS for family-run daycare centers that still juggle spreadsheets and phone calls. It wraps waitlist management, enrollments, and Stripe billing into a single dashboard with Tailwind + Hotwire on the front, Devise for auth, and Azure Blob for logos. Solid Queue handles scheduled jobs like weekly tuition and late fee automation so owners get predictable cash flow without hand-cranking invoices, while MailerSend keeps parents in the loop.
Right now I’m polishing the onboarding flow so new centers can import families, configure their billing cadence, and connect Stripe in under ten minutes. Next up is richer analytics (occupancy tracking and revenue health) and rolling out a guided setup for late fee policies. If you’re running childcare ops or know someone who is, I’d love feedback on the workflow pain points you still feel daily.
I've been grinding on kidcarekit.com for a long while in fits in spurts. I find myself working more on the DevOps side rather than the actual functionality but I've learned so much about rails and DevOps that it's been a net win for me even though it doesn't functionally do much yet!
Be careful if you see yourself spending too much time on the devops side of things. You can be building a tower of work that has zero customer value in the end.
Even the supposed quality improvements found in an automated way may just turn out very expensive compared to just spending the time doing the QA yourself at specific milestones. Unless your career is devops be very skeptical and track your time and return on that time.
I learned this the hard way although I am a build/devops person professional I came to realise I had a tendency to build really complicated processes that would be ok in a hundred person team, while I actually was working solo. The upside is that there is lots of reusability for future projects and I also became very skeptical of custom CI jobs and CD tools, and try to reduce everything to env variables 1 line bash scripts. I also am very skeptical of automated integration tests as they are incredibly expensive to build and maintain.
I wonder if (when) there will be a GGUF model available for this 8B model. I want to try it out locally in Jan on my base m4 Mac mini. I currently run Llama 3 8B Instruct Q4 at around 20t/s and it sounds like this would be a huge improvement in output quality.
It's a bit harder when they've provided the safetensors in FP8 like for the DS3 series, but these smaller distilled models appear to be BF16, so the normal convert/quant pipeline should work fine.
Edit: Running the DeepSeek-R1-Distill-Llama-8B-Q8_0 gives me about 3t/s and destroys my system performance on the base m4 mini. Trying the Q4_K_M model next.
Not trivial as long as imatrix is concerned: we've found it substantially improves performance in Q4 for long Ukrainian contexts. I imagine, it's similarly effective in various other positions.
reply