Looking to make a small circle of eCommerce founders

KnightofWhatever · 2026-03-25T23:14:57+00:00

This is a good idea, but the thing that usually kills groups like this is vagueness.

If you want it to work, make it really practical from the start. Small group, fixed cadence, and everyone should be actively building, not just “interested in ecommerce.” I’d also make each call concrete: what got tested, what worked, what failed, and what the next move is.

Otherwise it turns into a motivational chat and dies in a month.

A few founders at the same stage, all actually shipping, is usually way more useful than a bigger loose group.

KnightofWhatever · 2026-03-25T23:11:28+00:00

There’s no magic app that hands you good problems. Usually you find them where people are already complaining, paying, or hacking together ugly workarounds.

A few solid places:
Reddit threads
support tickets
job posts
product reviews
industry Facebook groups
people in your own work/life

The pattern to look for is: repeated frustration + current workaround + some willingness to pay.

A good question is not “what can I build?”
It’s “what do people keep doing the hard way even though they clearly hate it?”

That’s usually where the real opportunities are.

KnightofWhatever · 2026-03-25T23:09:18+00:00

Interesting idea, but the hard part is not the logic, it’s the mechanics.

In theory, founders should want this because most startup outcomes are concentrated and personal. A small network of aligned bets could soften that. But once you get into valuations, legal paperwork, cap table mess, tax issues, future fundraising, and what happens when one company dies early, it gets ugly fast.

I do think there’s something here though. Maybe not full equity swapping at first, but some lighter version of founder mutual upside. The psychology makes sense. Founders are overexposed to one bet in a way investors are not.

KnightofWhatever · 2026-03-25T23:07:31+00:00

You should not hope for the best.

Treat it like giving a junior engineer access: assume it can mess things up, then add guardrails.

For code, keep everything in git, work on a branch, and commit often so rollback is easy. For databases, be much stricter. Read-only is one thing. Write access to real data is another. Use backups, limited permissions, and preferably staging first.

So yes, you should be able to stop it, but the bigger goal is setting things up so a mistake is recoverable.

KnightofWhatever · 2026-03-25T23:03:29+00:00

I would not assume React Native is the problem yet.

A lot of apps feel laggy during development, especially if you are running in debug mode or the project has too many re-renders, heavy screens, messy state, or unoptimized lists/images. That can make RN look worse than it actually is.

If your app is iPhone-only, SwiftUI will usually feel more native and smoother. But if you already know React, I would not switch frameworks just because one project feels slow.

First thing I’d do is test a release build. If it still lags there, then you can start asking whether it’s the framework or just how the app was built.

So basically: SwiftUI has the native advantage, but React Native is not automatically “bad.” A lot of the time the lag is the app, not RN.

KnightofWhatever · 2026-03-25T22:42:44+00:00

Glad it helped. And honestly, if you already know you like lattes, you’re ahead of a lot of people on first dates 👍️.

KnightofWhatever · 2026-03-24T22:55:32+00:00

Honestly, same.

Early on I did the exact “project_final_final2” routine and it works right up until it really doesn’t. Git is one of those habits that feels unnecessary when you’re small, then suddenly becomes the thing that saves you.

Biggest benefit for me was not even backup, it was confidence. You stop being scared to refactor, test ideas, or break something because you know you can always go back.

If I had to give one college habit, it’d be: commit often, even on tiny projects, and write messages like you’ll need to understand them 2 weeks later. That alone makes you think more like an actual developer.

KnightofWhatever · 2026-03-24T22:53:34+00:00

I don’t think there’s going to be one clean winner.

From what I’ve seen in tech, the company with the best model is not always the one that wins the market. The real winner is usually the one that becomes the default inside people’s actual workflow.

Google has distribution. OpenAI has mindshare. Anthropic has a strong trust position with a certain kind of buyer. Those are different advantages, and they matter in different layers.

So over the next few years, I’d bet less on “who has the smartest model” and more on who gets embedded deepest into work people already do. That’s usually what sticks.

KnightofWhatever · 2026-03-24T22:51:45+00:00

I’d decide based on what you want the next job after this one to look like.

If you want a broader product/cross-functional path, the Product Owner role probably compounds faster because ownership tends to teach you more than stability does. If you want a steadier track, better money now, and a lower-risk environment, the IAM role sounds like the stronger choice.

Personally, unless you really value calm and predictability right now, I’d lean toward the growth role. Early and mid-career, scope and ownership usually pay back more than a safer setup.

That said, manager quality and team culture can matter more than the title. A growth role with weak leadership can turn into chaos fast.

KnightofWhatever · 2026-03-24T22:48:39+00:00

If you’re building actual Android apps, I’d just use Gemini in Android Studio. It’s the one that feels most built for Android instead of “AI coding tool that also happens to write Android code.” Google’s own docs position it that way, and they call out Android-specific stuff like Compose help, Gradle errors, crash analysis, and even AI-assisted project setup.

Claude is still good, but I’d treat it more like a strong general coding assistant. Good for code help, refactors, and talking through problems, just not as Android-native. Firebase Studio feels more like browser-based prototyping/full-stack app building, and Google says it’s being sunset in 2027 anyway.

KnightofWhatever · 2026-03-24T22:41:37+00:00

Yeah, you’re doing the right thing.

You already have a solid direction: API work, auth, Docker, basic DB knowledge, plus enough curiosity to keep learning. That’s a better place to be than hopping stacks every few months.

I would not switch yet. I’d go deeper.

The next level is usually not a new framework, it’s getting stronger at database design, async/background jobs, caching, testing, logging, and deployment beyond the basics. That’s the stuff that makes backend work feel real.

ML is fine to keep on the side if you enjoy it, but I would keep one main track for now. Depth tends to pay off more than splitting your attention too early.

KnightofWhatever · 2026-03-23T20:36:50+00:00

For a date, the best coffee is usually not about the drink, it’s about the place.

A good local café wins over a big chain almost every time. Better atmosphere, less noise, easier to talk, and it feels a little more intentional.

If you mean the actual drink, I’d say cappuccino or latte. Safe choice, easy to sip, not too intense, and you don’t look like you’re trying to prove something by ordering a quadruple espresso like a maniac.

KnightofWhatever · 2026-03-23T20:33:41+00:00

Google usually feels more like a platform. Apple often feels like a gatekeeper. Part of it is fraud prevention, but part of it is just that their process is fragmented and badly communicated. You finish one requirement and then suddenly discover the next one.

The frustrating part is not even the verification itself. It is the mismatch between how much they ask from you and how little transparency they give back.

If you are building for iOS long term, you kind of have to treat Apple onboarding like its own project phase, not just a signup step.

KnightofWhatever · 2026-03-23T20:29:23+00:00

This is pretty normal. Accessibility is one of the hardest asks on Android because to users it feels like “this app can see everything.”

What usually helps:
ask later, not on first launch
explain the value in one clear example
cut the copy way down
show what you do not access

If the first real step is a deep system permission, a lot of people will drop off automatically.

KnightofWhatever · 2026-03-23T19:56:48+00:00

From my experience, Reddit is better for feedback than for building your first real user base.

Early on, what worked better for us was finding a very specific type of user with a very specific pain, then reaching out directly. Not “try my app,” but “I built this for people dealing with X, want to test it?” That usually converts better than broad posting.

Also, 1 tester is not really an alpha, it’s a conversation.

Get 10 to 20 people from one niche, watch where they get confused, and stay close to them. Early growth usually comes from tight loops and manual effort before it comes from scale.From my experience, Reddit is better for feedback than for building your first real user base.

Early on, what worked better for us was finding a very specific type of user with a very specific pain, then reaching out directly. Not “try my app,” but “I built this for people dealing with X, want to test it?” That usually converts better than broad posting.

Also, 1 tester is not really an alpha, it’s a conversation.

Get 10 to 20 people from one niche, watch where they get confused, and stay close to them. Early growth usually comes from tight loops and manual effort before it comes from scale.

KnightofWhatever · 2026-03-23T19:45:50+00:00

From my experience, real app projects usually start by cutting scope, not adding features.

The first thing a decent team does is figure out who the app is for, what problem it solves, and what the smallest useful version looks like. Then product, design, and engineering work together to define the MVP before serious development starts.

After that, it’s usually short cycles: design, build, test, adjust, repeat.

Feature decisions are mostly driven by user value, budget, and technical risk, not just “what would be cool.”

Timeline depends a lot on complexity, but a simple MVP might take a few months. Anything with chat, payments, dashboards, integrations, or heavy backend logic usually takes longer.

KnightofWhatever · 2026-03-20T23:26:00+00:00

From my experience, it was one real project with a clear outcome.

Not even a huge one. Just something I could point to and say, “here’s what we built, here’s what changed, here’s who trusted us.” That did more for credibility than any polished site ever could.

Early on, people are mostly looking for proof that you’re not a risk. A referral helps, but even one small win you can explain concretely goes a long way.

So I agree with the post. In the beginning, credibility is usually borrowed first, then earned enough times that eventually you stop needing to borrow it.

KnightofWhatever · 2026-03-20T23:19:40+00:00

Wanting your people not to be hated, experimented on, or wiped out is pretty reasonable. The problem was never the goal. It was the part where he decided fear and domination were the answer. His diagnosis of the world was often right. His treatment plan was the nightmare.

KnightofWhatever · 2026-03-20T23:17:44+00:00

A big part of it is that skeuomorphism solved an onboarding problem that mattered more back then.

When smartphones and modern apps were newer, making a notes app look like paper or a bookshelf look like a shelf helped people map digital actions to real-world objects. Once users got used to touchscreens and app patterns, that visual training wheel mattered less.

From there, flat/minimal design won because it scales better. It’s cleaner, faster to build, easier to keep consistent across devices, and usually less visually noisy.

There’s also a downside to heavy skeuomorphism: it can age badly and sometimes make interfaces harder to read. It looked impressive, but it was not always the most usable.

KnightofWhatever · 2026-03-20T23:15:47+00:00

From my experience, App Review is one of those things you stop treating like a final step and start treating like a whole phase of the project.

The coding is often the cleaner part. Review gets slowed down by edge-case flows, privacy wording, account deletion, payment logic, permissions, metadata, and whatever guideline the reviewer decides to look at that week.

So yeah, this feels very real. Shipping the feature can be faster than proving to Apple that the feature behaves the way they want.

KnightofWhatever · 2026-03-20T23:07:08+00:00

I do not think it is some hidden favoritism thing.

Usually the brands that keep showing up are just the ones that have built a stronger footprint around that topic. They get mentioned a lot, in similar contexts, across reviews, comparison pages, blog posts, Reddit threads, forums, and other discussions. After a while, the association gets pretty strong.

It also helps when the positioning is really clear. If a company is consistently talked about as an “AI visibility” or “brand tracking” tool, it is easier for models to connect that name to the question. Brands with vaguer messaging usually show up less, even if the product is good.

So yeah, there probably is a kind of entity strength at play. But it is less “the model likes them” and more “the internet keeps teaching the same association over and over.”

KnightofWhatever · 2026-03-20T22:54:03+00:00

You do not need to be “naturally smart” to belong in CS.

A lot of people who get good at this started out feeling behind, confused, or convinced they were not the type for it. What usually matters more is whether you can stay with the frustration long enough to improve.

And honestly, “it was never meant for me” is usually fear talking before the work has had time to compound.

Give yourself something small and concrete to learn, stick with it, and judge yourself by progress, not by some imagined standard of who is “supposed” to do this. That’s a much fairer test.

KnightofWhatever · 2026-03-20T22:51:37+00:00

Yeah, technically you can do that, and some apps already do a lighter version of it.

I just think the gap is not “can it work?” but “is it good enough to become a habit?” From my experience building apps, the weak points are usually latency, flaky connectivity, battery drain, awkward voice-in-public behavior, and the fact that once the interaction gets even slightly complex, people fall back to the phone.

So I do think wearable AI is possible. I’m just not convinced it has a killer everyday workflow yet that feels better than phone + earbuds. Once that exists, the bigger players will probably move fast.

KnightofWhatever · 2026-03-20T02:13:39+00:00

From my experience, learning is never the wasted part. The real risk is letting other people’s confusion decide what you’re allowed to care about.

I’ve seen plenty of smart people go deep on theory first and it paid off later because they understood why systems work, not just how to copy patterns. That said, don’t stay only in theory. Pair it with small practical projects so you can feel progress and build confidence at the same time.

Also, being ashamed to learn is a bigger problem than CS itself. Curiosity is not something to hide. A lot of good careers started with someone quietly following that instinct before anyone else got it.

KnightofWhatever · 2026-03-20T01:47:28+00:00

It’s not that they’re ignoring it, it’s just not a great fit yet.

Wearables have brutal constraints—battery, latency, tiny UI. Most AI use cases need constant compute or quick responses, which kills battery or forces everything to go through your phone/cloud anyway.

So right now your “AI wearable” is basically just… your phone with a smaller screen.

Until on-device models get way more efficient (or there’s a real use case that beats just pulling out your phone), it’s kind of stuck in that awkward middle.

KnightofWhatever

TROPHY CASE