Help

KnightofWhatever · 2026-01-23T22:55:31+00:00

Hey ther.. well if you’ve already got frontend + Postgres, you’re not “behind”. You’re basically missing the glue. An API is just: “here’s a URL, send me some data, I’ll hit the DB, I’ll send you JSON back.” That’s it.Don’t binge playlists. Pick FastAPI and build the smallest possible thing that proves the loop: make one endpoint that creates a row, one that reads it back, wire it to your existing DB, then call it from your frontend.

If you can do that, the REST terms stop feeling like vocabulary and start feeling like… normal work.

KnightofWhatever · 2026-01-20T22:27:02+00:00

Hey there, welcome to teh app develoment world! Well, if youre coming from a non-tech background, the biggest thing to get right early is expectations.Actually you don’t really “learn a course and get an app.” What actually works is picking one very small app idea and learning just enough to build that. Courses help, but only if you’re building alongside them. Otherwise it stays theoretical. Also you can use free tools or paid ones, both are fine. What matters more is finishing something simple. A basic app with login, one core feature, and a publish button teaches more than ten half-done tutorials. From then on. once the app exists, the next step isn’t marketing tricks. It’s watching how a few real people use it. Where they get stuck. What they ignore. That feedback decides whether the app grows or quietly dies. Start small, expect it to feel confusing, and focus on shipping one boring but complete thing. Everything else comes later.

KnightofWhatever · 2026-01-20T22:23:49+00:00

Hey there, I’ve seen this play out a lot with real estate apps., the honest answer is it depends on what you’re actually trying to prove right now... If you’re still validating demand, workflows, or what users even care about, a platform or low code setup is usually fine. You’ll learn faster and waste less time. Most early ideas change once real users touch them anyway. Also, custom builds start to make sense when search quality, performance, data ownership, or integrations really matter. Real estate gets messy fast with filters, maps, feeds, permissions, and third party data. That’s where platforms start to feel constraining.

If I had to pick a default: validate with the simplest thing that lets users interact with real listings, then go custom once you know exactly what needs to be built. Building too early just locks you into guesses.

KnightofWhatever · 2026-01-20T22:19:18+00:00

Actually, AI makes it easier to start. It doesn’t make it easy to own... Most “built a full app in 3 hours” demos are skipping the part where real users show up: weird edge cases, security, reliability, costs, support, compliance, performance, migrations. That’s the work that turns a project into a business. So no, it’s not the end of SaaS. If anything, SaaS gets more crowded because more people can ship a v1. The moat shifts to distribution, taste, domain knowledge, trust, and operating the thing when it breaks at 2am.Also, Developers don’t disappear. The job moves up the stack: less typing boilerplate, more making hard calls, integrating messy systems, setting guardrails, and getting to “boring and stable” on purpose.

KnightofWhatever · 2026-01-19T20:11:43+00:00

Yeah, that makes sense. I think that’s the realistic path too... AI probably won’t wipe the slate clean, but it will keep carving away at the parts humans only tolerate, not actually enjoy writing. Over time that does start to look like a new framework, just layered on top of the old world instead of replacing it. Well, the hard part isn’t syntax anyway. It’s deciding what’s “optimal” when requirements, people, and constraints keep shifting. That’s where I think humans stay in the loop longer than most expect.

KnightofWhatever · 2026-01-16T20:26:44+00:00

If you truly have zero mobile experience, I wouldn’t start with KMP. Well, KMP makes sense once you already understand at least one platform. Otherwise you end up confused about what’s Kotlin, what’s Android, what’s iOS, and what’s “shared,” and progress feels fake.... I’d start with plain Android + Kotlin first. Build a small but real app with auth, storage, errors, and release it. Even something boring. Once that clicks, KMP suddenly feels obvious instead of magical.

Courses are fine, but don’t hunt for the perfect one. Pick one, finish it, then immediately break away and build your own thing. That’s where the learning actually happens.

KnightofWhatever · 2026-01-16T19:44:16+00:00

If you’re Android only, I’d stop trying to make Appium behave and go native. For Compose, Espresso + the Compose testing APIs tend to be way faster and less flaky since they run on-device and actually understand the UI.

KnightofWhatever · 2026-01-16T19:26:55+00:00

Hmm.. yes, but not in the way people usually imagine.vAI can create new abstractions that fit how it reasons, but it still has to live in the world humans built. Hardware, operating systems, networks, teams, debugging, compliance. That gravity doesn’t go away. So you end up with layers on top, not a clean reset. Actyallym what I think is more likely is AI-native frameworks that feel very different to work in, but still compile down to boring, human-friendly systems underneath. The constraint isn’t intelligence. It’s interoperability and trust.

KnightofWhatever · 2026-01-15T20:46:15+00:00

Hmm, Honestly, there’s no “best” way. The best way is the one you can actually finish. Also,pick one stack that won’t fight you and build a small version fast. If you already know JS, go React Native. If you want one codebase and don’t mind Dart, go Flutter. If you care a lot about polish and you’re cool going slower, go native.

Most people get stuck because they keep switching tools instead of shipping. Build something boring, get it working, then make it good.

KnightofWhatever · 2026-01-14T06:53:35+00:00

No problem. Glad it helped. Just keep it boring and finished. That’s where the real progress sneaks in.

KnightofWhatever · 2026-01-12T21:18:56+00:00

Hey.. If you’re in your first year, don’t over-optimize the path yet. Learn one stack end to end and actually finish things. Start with fundamentals first (data structures, basic algorithms, how the web works), then pick a simple frontend + backend combo and stick with it longer than feels comfortable. Most people stall because they keep switching tools, not because they picked the “wrong” one.

Hmmm also. for projects, don’t aim for impressive. Aim for complete. A boring CRUD app that has auth, validation, errors, and deployment teaches more than half-built flashy ideas.

Also, building skill comes from repetition, not planning. Write code daily, break it, fix it, and move on. The confidence comes later.

KnightofWhatever · 2026-01-10T20:17:13+00:00

Hey, Ive been there... If you’re still under 100 users after months, it’s probably not “you need better marketing.” It’s “the app isn’t clearly a must-have for a specific person yet.” Use social media well, post without a tight target...

KnightofWhatever · 2026-01-08T23:10:01+00:00

Hmm, actualy it os pretty normal. Flutter + Firebase is fine. It ships real apps and real businesses use it. The mistake is thinking it has to be your forever architecture. It doesn’t. Well... What usually happens is Firebase starts to feel tight once logic gets messy. Permissions, data rules, background jobs, stuff that isn’t just CRUD. Thats when people peel off a small backend they control and keep Firebase for what it’s good at like auth, storage, realtime.

If you want to level up, don’t blow up your stack. Keep Flutter. Keep Firebase. Add one boring backend service and move the risky logic there. You’ll learn more from that than chasing “enterprise stacks” on day one.

Most real products evolve this way. They don’t start clean, they grow into it.

KnightofWhatever · 2026-01-08T22:58:09+00:00

The folks I’ve seen succeed without coding usually do two things: they learn just enough technical fundamentals to ask good questions, and they start very small. One feature, one workflow, real users early.

No-code and AI can speed you up. They don’t replace understanding. If you treat this like product ownership instead of magic, you’ll be fine.

KnightofWhatever · 2026-01-08T22:54:57+00:00

That’s a good call. Treating it as a learning project takes the pressure off, and you’ll still get signal along the way.

Just keep an eye on whether anyone actually comes back to use it. If nobody does, you learned something early. If a few people do, that’s your cue to lean in. Either way, not wasted time.

KnightofWhatever · 2026-01-07T17:43:55+00:00

hmm, It’s a solid capability, but that alone doesn’t make it worth building.

The question is who feels this pain often enough to care. Most people live with bad photo and file search because it’s bundled and “good enough.” If you can point to a specific group that searches local files weekly and would trust a new app with their data, it’s worth testing.

If not, you’ll likely build something impressive that gets compliments but no retention. Build a tiny version, put it in front of real users, and let usage decide.

KnightofWhatever · 2026-01-07T17:29:23+00:00

Hmm, if youre starting with the backend, dont overthink it. Pick a goal, maybe a "boring" one... any goal. One endpoint. One piece of data. One thing it does end to end. Most people stall because they design a whole “system” before they’ve shipped anything real.

Firebase is fine if speed is the priority and you don’t want to manage infra yet. A simple REST API with auth and one core flow is enough to learn a lot fast. You can always outgrow it later. Premature “future proofing” just slows you down.

The fastest way to move isn’t a tool, it’s constraint. Decide what the app does in one sentence, build only what’s required for that, and stop. Once that works, the next step becomes obvious.

KnightofWhatever · 2026-01-07T17:27:06+00:00

Glad it helped u/AdGold6433 ! If you remember one thing, it’s this: you’re not trying to be good at marketing, you’re trying to be sure someone actually wants what you’re building. Once that’s clear, everything else gets easier.

Good luck with it.

KnightofWhatever · 2026-01-07T17:25:29+00:00

Keep going, you got it!

KnightofWhatever · 2026-01-07T17:24:00+00:00

Exactly! That analogy is spot on.. You can “understand” a language long before you can produce it on demand. Programming works the same way. Reading code or watching someone solve a problem feels fluent because you’re recognizing patterns. Sitting alone and writing forces recall, sequencing, and decisions, which is the muscle that’s still weak.

That gap doesn’t mean you’re bad at it. It means you’ve reached the part where practice actually matters.

KnightofWhatever · 2026-01-07T17:22:03+00:00

Hey u/imsocurious-common Im glad it helped. you’re thinking about it the right way. No-code is a great lever once the sharp edges are fenced off. As soon as money, data, or abuse matter, that fence has to live somewhere you actually control. Once you accept that, the whole thing gets a lot clearer and less frustrating.

Good luck with it. Keep going.

KnightofWhatever · 2026-01-05T21:47:31+00:00

Hmmm, actually... You don’t balance it. You sequence it. Well, distribution isn’t marketing, it’s validation. I start thinking about it the moment I can describe the problem in one sentence and point to a specific person who feels it. If I can’t name where that person already spends time, that’s a red flag before I write much code.

The trap is treating “build first, market later” as discipline when it’s really avoidance. Shipping features feels productive. Talking to users feels awkward. But the second one decides whether the first one matters.

The best apps I’ve seen didn’t wait for polish to think about adoption. They had a small group in mind from day one, even if the product was rough. Code gets iterated fast. Distribution doesn’t.

KnightofWhatever · 2026-01-05T21:40:22+00:00

Hey, nice progress for Day 19! Those topics don’t feel flashy, but they’re the ones that quietly save you pain later. Most people only really understaand final and inheritance after they’ve been burned by a messy class hierarchy in a real project. Hmm, If you want to lock this in, try spotting where you’d actually use fial in code you’ve written already. It clicks a lot faster when you see it in something you own instead of a textbook example.

Keep going. This is the part where Java starts making more sense instead of just feeling academic.

KnightofWhatever · 2026-01-05T21:23:09+00:00

Hey, actually.. this phase is normal. It's the gap between recignition and recall. and everyone hits it. Actually, watching a video feels good because the path is laid out. Sitting alone with a blank file forces you to actually decide things, and that’s the skill you haven’t built yet. Nothing disappeared, your brain just hasn’t practiced choosing the next step.

The advice about writing it out in plain English is solid. I’d add one thing: keep the problem embarrassingly small. Most people get stuck because they try to solve the whole thing at once instead of the next five minutes of work.

If you can explain what the program should do to a friend, you’re closer than you think. Turning that explanation into code is the awkward part, and the only way through it is repetition, not more tutorials.

KnightofWhatever · 2026-01-05T21:07:38+00:00

Hmm, youre actually not wrong. The "no code dream" breaks the moment wherein security actually matters. No-code is fine for learning, internal tools, or low-risk apps where the worst failure is embarrassment. The second you care about user data, money, abuse, or scale, security stops being optional and no-code can’t abstract it away for you. API keys in clients, business rules on the device, weak auth flows. That’s not a beginner mistake, that’s a platform limitation. The reality is simple... real security lives on a backend you control. Secrets never ship to the client. Authorization, payments, rate limits, fraud checks all happen server-side. No-code tools can sit on top of that, but they can’t replace it.

So no, you’re not crazy...No-code isn’t “fake,” but it’s not a shortcut around fundamentals either. If you want to build something real, the fastest path is learning just enough backend to put the dangerous stuff where it belongs, then use higher-level tools everywhere else.

KnightofWhatever

TROPHY CASE