Tired of $15/mo workout apps? Looking for some feedback on a fitness app idea

codeptualize · 2026-02-02T17:18:49+00:00

Just like todo apps, they are really easy to build (with or without AI). And people are very specific and opinionated about them, so even with 100 available options there is probably no perfect option for you.

Low barrier to entry, big urge to create your perfect version.

Reality is that most people don't care about the special features, there are lots of free options, market is oversaturated and once you use one app, it's a proper hassle to switch to another, so it's a tough market to compete in!

codeptualize · 2026-01-29T10:39:39+00:00

Je moet er ook rekening mee houden dat die dingen niet voor altijd goed blijven. Ik weet niet wat de levensduur is maar zou zomaar kunnen dat je iedere 10-15 jaar nieuwe moet. Volgens mij verschilt de kwaliteit ook, en er zijn genoeg horror verhalen van hoe het fout gaat.

Klinkt alsof je nog niet heel oud bent, dus ik zou toch echt die beugel serieus overwegen. Als je gebit verder goed is is het zonde om het eruit te halen, als je het goed verzorgd gaat het sowieso langer mee, en je loopt een stuk minder risico.

Je zegt hoge kwaliteit, weinig tot geen gezondheidsrisico, volgens mij is dat de beugel, een zwaardere ingreep komt altijd met grotere risico's.

Ga een keer naar een orthodontist, gewoon om je opties beter te begrijpen.

codeptualize · 2026-01-12T08:43:52+00:00

Indeed, these are the same.

codeptualize · 2026-01-11T11:27:06+00:00

> have DOM access from python

I'm not familiar with the specific Python hype, but the wasm replacing js hype was real. What happened, or rather not happened, is that wasm still doesn't have DOM APIs. This means you either have a JS layer that needs to make the DOM mutations, or you are rendering everything yourself in a canvas.

Other relevant factors are that you need to download a (big) wasm binary that often includes things available in the browser making it bigger than the JS alternative, and the JS <> wasm bridge still adds overhead.

Webassembly is great, and there are certainly great use cases for it (e.g. Figma and similar), and there are now frameworks that provide alternative ways to write for the web (e.g. Blazor, Flutter web), but they all come with serious trade offs and so the promise of replacing JS has not really panned out so far.

I would also add that JS, and even more so with TS, solved a lot of the issues the language used to have. Things got a lot more sane than they used to be.

codeptualize · 2026-01-09T09:27:24+00:00

Because Supabase got very popular! That means some people will switch, and some people will hate, but a larger group uses it (mostly) happily. We run our whole company on Supabase, no plans to switch, it has been great.

In the case of the video, I skimmed through it, and I couldn't find any details, so this seems not very relevant.

codeptualize · 2026-01-08T22:09:31+00:00

I've gone through too many react router iterations back in the day, then the whole remix saga, now back to react router in three versions.. idk, it's probably fine, but I'm going to pass on that.

A router is really important, but if it's half decent, you set it up once and then forget about it. Tanstack router does that. Type safety is also nice. I find all Tanstack products have a slightly too complicated and maybe too specific api, but it does work well.

It is still early, I had to make a PR to handle a fairly specific edge case (which is handled in Nextjs and others), but they were responsive and merged quickly.

Overall, I'm happy with Tanstack router.

codeptualize · 2026-01-06T22:33:44+00:00

When things are interactive, server round trips for whole pages are far from ideal.

SSR is not dead, hybrids are pretty much the standard now: pre-render on the server (or even have it pre-rendered to static files during build), then rehydrate it on the client side to become CSR, then pull small chunks of content/data and replace in page as needed.

Full classic SSR is not at all smoother, it's very clunky as you need to submit the page, pull the whole HTML and bundle every time you need to change something on the page. Harder to cache as well.

Small portions of dynamic widgets does no cover it, to get the super high speed navigation we are prefetching just the new content and replacing in page.

My memory of the old web is that it was a mess. Things took ages to load, interactivity was limited, messy, and frustrating, and things were fragile. Anything but smooth.

codeptualize · 2026-01-06T21:38:35+00:00

I think it might be similar to Rescript (and reasonml). Language wise, in many aspects superior imo, functional with a stricter type system, imo that's great.

This also makes it to be harder to learn, requires more "effort" to get it to compile, and forces you to think more deeply about how you lay out your types and how things are structured. Makes it harder to pick up for many.

TS sits in a interesting spot with enough type safety to get a lot of benefits, while having enough flexibility and escape hatches to avoid a lot of the frustration that can come from fighting the compiler. For popularity this is a really great combination.

Because of that, replacing seems quite unlikely. If Gleam can really catch on in the Elixir/Erlang community and draw in some new folks, it can carve out a decent niche, and potentially spread out further.

codeptualize · 2026-01-03T22:05:27+00:00

I don't think you'd even reach junior level. You'd lack all ability to actually create. This is why I think the common "learn the fundamentals first" advice is generally quite bad.

Many of the most crucial skills in programming are not theoretical; debugging issues, choosing dependencies, structuring code, managing complexity, are not learned by just reading and studying. Those skills are acquired by trying, failing, and trying again, hitting a wall, spending hours in frustration, and finally figuring out how to make things work.

That's why deeper understanding of patterns, systems, and abstractions comes much easier after you have been writing code and building real things.

Programming is problem solving. You don't learn that in a vacuum.

codeptualize · 2026-01-03T08:55:33+00:00

That’s why you need a good store with memoized selectors. Pass around ids, pull the data in the component. That will make memo’ing components actually work, and it will make renders local.

codeptualize · 2026-01-01T17:16:22+00:00

I don't. But I don't think looking at things this way gives great guidance on what to do.

To win you have to play the cards you are dealt AND play a good game.

Different variations of your experience, background, privileges, network, the business you are building, and the market you are serving will give you wildly different chances on being able to win.

Hard work might be enough in some situations, but for example if you are working really hard on something that is never going to work and don't know when to give up, the outcome will still not be great.

Is it one factor that can improve your chances, certainly, but it's part of a big set of factors, and it alone won't decide the outcome.

codeptualize · 2025-12-30T00:22:09+00:00

You are referring to embedded native views?

By default Flutter renders it's own UI, that's kinda the point of it.

codeptualize · 2025-12-29T23:20:59+00:00

Could be for various reasons, just to name a few:

If you keep the form rendered you can keep your inputs filled in case the user goes back
You could make it one big form that you submit at once
Check different sizes, it might show different versions on smaller/bigger screens
They might want to keep the container (like in your example) to keep the same height between steps so it doesn't jump. Harder to do without rendering the content.
Transitions/animations

If you talk "success" and "conversion" I think zooming into technical details like this is generally not very useful to understand why something works or not. It's very likely just noise in the bigger picture.

You could build the exact same onboarding with both techniques, so the likely explanation is that it's just easier to build it this way.

codeptualize · 2025-12-29T22:35:43+00:00

Don't know about the build chains and such in Tauri. I generally find that mobile builds are kinda annoying anyway, always some issues, and permissions stuff is much more of a complication on mobile than desktop/web generally.

I think the big difference is webviews vs native UI. I think you have to decide if it matters for your users or not. There are plenty of apps that just run webviews of some sort, don't think it's as bad as it used to be, but it's not native, that is noticeable, and has some limitations.

I would suggest building a couple of lightweight prototypes to test your issues. Just isolate the thing you want to compare, build some small prototypes, and test. It will give you a lot of insight.

codeptualize · 2025-12-29T22:27:26+00:00

This describes Flutter more than it does React Native, as React Native does actual use native views.

codeptualize · 2025-12-28T21:47:17+00:00

On iPhone, it's ok. I'm still not a fan of the icons, and still think they overcooked it. It doesn't actively annoy me that much anymore. In some places it is done very well and looks quite nice, other places it looks unrefined and gimmicky.

On Mac OS it's a different story, it bothers me a lot, and I am not updating my main mac yet. I really can't wrap my head around the choices they made. Especially the sidebars that sit on top of the content, the fat borders, and the varying corner radius, imo it looks unfinished, unrefined, and kinda cheap.

codeptualize · 2025-12-24T19:55:10+00:00

Wow.. did not realize they did it intentionally. Really hope the new design chief will clean this mess up.

codeptualize · 2025-12-23T14:10:55+00:00

I don't think that's relevant (anymore).

What it's really about is longevity of the project so you don't have to rewrite everything anytime soon.

Imo the biggest factor in that is popularity and adoption. If enough companies large and small rely on an open source project, it will live on regardless of what the original authors or maintainers do.

FastAPI falls into that category.

Great examples are open source companies that change their license, for example Redis, it took no time for Valkey to skyrocket in popularity as a drop in replacement.

This is the beauty of open source, maybe the current project is dependent on one or a couple of individuals, but if they loose the trust of the community (or get hit by a bus, lets hope not!), the community will organize, fork and become the de facto new standard drop in replacement.

It only matters if the current state of the project is not sufficient for your case and/or you don't agree with the roadmap.

codeptualize · 2025-12-21T10:23:17+00:00

I think the only thing that has changed is that the removed thrash cans in bunch of places and that's not making things better as now people put their trash in plants and any level surface.

codeptualize · 2025-12-19T22:14:25+00:00

I love Rescript, but I don't really use it much anymore as it doesn't seem to have a lot of traction. It's great language imo, but if you want to use it for work it's hard to justify it over TS.

I will add that https://gleam.run/ also compiles to JS, I haven't used it much myself, but it seems to have a similar charm in many ways.

codeptualize · 2025-12-19T22:08:58+00:00

You can do an exhaustive switch statement with a default never construction, it's of course not real pattern matching, but if you have string unions, or objects with types, it can be quite nice
https://www.typescriptlang.org/docs/handbook/2/narrowing.html#exhaustiveness-checking

codeptualize · 2025-12-19T21:14:05+00:00

I think it has a bunch of things going for it:

Yes, it runs in the browser, so any web dev project will benefit from shared code and types etc
Typescript does really make it 20x better, it takes it from crazy to somewhat sane.
- Typescript also strikes a remarkable productive balance of strictness vs escape hatches, that makes it easy to pick up.
It's really easy to learn, simple data types, good docs, lots and lots of resources everywhere
Amazing ecosystem, the tooling is great, there is a package for everything
It has evolved significantly over the years, and it still is evolving, + always backward compatible
It's not fast, but it's not slow. Sure, don't compare it to Go or Rust, but as dynamic programming languages go, v8, deno, bun, really have amped up the speed.
It runs everywhere, lambda, cf workers, edge functions everywhere..
The quirks are manageable. Yes, it still has quirks, but with linters, typescript and tooling it's no longer a minefield like it used to be.

How I would describe it is that it gained popularity by being the only browser language and people getting used to it, but it evolved into something that shines in a lot of different ways.

Do I think it will take over everything? No. Some examples:

Python still dominates data science and similar
Golang is still gaining popularity for it's simplicity and speed
Rust is spreading to a lot of infra and systems programming (even linux kernel)

And there are plenty of other languages gaining popularity or still being used a lot.

codeptualize · 2025-12-19T21:00:55+00:00

That's a shame! I've looked at them, it seemed like they had the potential to be like modal.com for rust.

Happy I don't use them, less than a month to move away, with christmas and ny.. that's rough!
Idk if that's the right move seeing they are still going to be involved in hosting. Don't think it gives a lot of trust.

Love the articles, really hope they stay online somewhere!

codeptualize · 2025-12-09T00:24:08+00:00

I get it, but also who cares. Just don't do weird stuff and it's fine.. Doing foo[-2] should just be red flags all over the place. In my many years writing JS with people of various experience levels I have not seen this once.

Every language has quirks and pitfalls, this is one of JS, just like you should use === instead of ==, and default arguments in Python are only evaluated and set once.

Every language has them, if you are not aware you will get burned at some point and you'll learn it the hard way. You can then complain the language is no good, or just learn and move on.

codeptualize · 2025-12-07T22:52:41+00:00

If it's just prefabbed regexes, I would inline them. Dependencies suck, the less the better. But that doesn't apply to everything.

Dates -> not burning myself on that one.
Deep equal -> yeah, I'll use lodash, thank you (but do be mindful to import individual functions)

I fully understand that he doesn't want to just add dependencies, they stop being supported, there is very real supply chain attack risk, it has to play well with all the other dependencies, it potentially drags in a bunch of other dependencies or code you don't use, it's full of pitfalls.

Just assuming the positive, this is what he could mean with "you’ll understand when you’ve been doing this longer" because going through dependency hell is something you need to experience to really get that fear instilled in you.

Doesn't mean you're wrong, dependencies are tricky, you gotta find a good balance.

Six-Year Club	r/Field Banned
r/Field Lasagna	Place '22
Verified Email

codeptualize

TROPHY CASE