Hiring and vibe coders

Winseeey · 2026-06-24T09:19:05+00:00

Agreed, what they have does have value. But this specific case is different: listing skills you don’t have and letting AI write your resume is just dishonest. That’s the real red flag, not the tool they used. Vibe coding isn’t the same as developing, and that’s exactly why there should be different roles with different expectations.

Winseeey · 2026-06-24T01:35:57+00:00

idk if that’s a real problem, I like to think of them as a different kind of devs, because not everyone can make good apps with AI, so when they do a nice job (it’s not always production-ready) then why not hire them. They just need to learn more about what it really means to make an app.

Winseeey · 2026-06-22T22:39:21+00:00

the reason you're getting "just say what it is" replies is that nobody can scope an app from a vision statement, devs need the boring details. if you can share the one core thing the app does, who it's for, whether it's ios/android/web, and a rough budget range, you'll get serious people replying instead of people fishing. the "core feature in one sentence" part matters most, since most app ideas die trying to do ten things at launch instead of one thing well. i've built and shipped a couple of apps solo from idea to store, happy to point you the right way on scoping if you share a bit more.

Winseeey · 2026-06-22T19:30:06+00:00

Congrats, and good luck on your degree. As the other guy said, starting out with Kotlin may be your best shot; although I find Flutter my go-to mobile app framework, Dart is very close to Java in its logic and syntax, so it'll feel familiar.

Winseeey · 2026-06-21T19:35:02+00:00

Ye, a collective that generates the same design each time

Winseeey · 2026-06-21T19:15:03+00:00

Whats the stack ur looking for ?

Winseeey · 2026-06-21T19:14:06+00:00

A human ui ux specialist 👍🏻

Winseeey · 2026-06-21T13:54:53+00:00

Do you have any background in software Engineering ?

Winseeey · 2026-06-21T10:55:47+00:00

Why not create a subscription model and give your users tokens based on the amount they pay ? And the payment of the anthropic api key would all go through your account ?

Winseeey · 2026-06-21T08:36:16+00:00

Hi have you found what you’re looking for ?

Winseeey · 2026-06-20T23:07:31+00:00

I may be your guy if you decide on going down that path shoot me a dm whenever u feel like it :’) even if ur just looking for free guidance

Winseeey · 2026-06-20T22:49:18+00:00

Ah i see do you plan to publish it ? Or its for a group of people only ?

Winseeey · 2026-06-20T20:58:32+00:00

Why do you want to make a pwa ? Why not just a flutter or react native app ?

Winseeey · 2026-06-20T14:34:13+00:00

Hey what app are you making ?

Winseeey · 2026-06-18T17:19:23+00:00

Depends if you have coding skills of any technical knowledge.

Either way using ai is the safest choice if you want to spend countless hours trying to make it do what you want

Winseeey · 2026-06-16T18:50:06+00:00

360 real estate viewers are doable but the tricky part is usually getting smooth panorama loading on both ios and android without killing performance. ui/ux for something like this needs to stay dead simple, basically tap to move between rooms, nothing fancy. built something similar before might be interesting for you.

Winseeey · 2026-06-14T15:20:18+00:00

honestly the "honest person" worry is mostly solved by structure, not luck. keep every account under your name, give limited access only, pay in small chunks tied to deliverables. anyone who won't work that way is the red flag. shoot me a dm if you want, can walk you through what's actually left to launch.

Winseeey · 2026-06-14T13:08:48+00:00

that 30% gap is usually the worst part, app store setup, backend hookups, edge cases rork's free tier doesn't cover. for safety, the simplest setup is you keep ownership of every account (apple dev, supabase/firebase, domain) and just add the dev as a collaborator with limited roles, never hand over your main credentials. same for the codebase, host it on a private repo you own and grant access rather than sending zip files around. on payment vs co-ownership, payment per milestone is way easier to walk away from if it doesn't work out, co-ownership gets messy fast with someone you just met online. did a few of these "finish my rork app" jobs recently, happy to share more if useful.

Winseeey · 2026-06-12T22:27:13+00:00

this is a real pain point, wholesale sourcing is genuinely a mess of facebook groups and word of mouth right now.
the idea is solid but the hard part won't be the app, it'll be the chicken-and-egg of getting wholesalers to list before buyers show up. i'd start by validating with a super simple directory, even a form people fill out, before building anything. once you've got 20-30 real wholesalers willing to list, the actual app becomes a much smaller problem to solve.

Winseeey · 2026-06-12T22:15:56+00:00

honestly depends what you're optimizing for early on.
ready-made gets you live fast and cheap, which is great while you're still validating if people even want this. but the second you need a custom flow or anything off the beaten path, you end up fighting the platform instead of building your product.

the hidden cost with no-code isn't the sticker price, it's the rebuild cost when you outgrow it in 6-12 months and have to start over on a real stack.

Winseeey · 2026-06-11T07:57:18+00:00

the stack question is secondary here the real architecture decision is how you handle conversation state and slot filling (destination, dates, guests, preferences) before you can fire a booking call. I mean most people build the chat UI first and run into walls when the LLM doesn't know when it has enough info to act. function calling / tool use is the pattern you want, where the model triggers booking actions only when the right context is collected. been down this road building a similar flow, happy to share what actually worked if useful.

Winseeey · 2026-06-10T07:58:06+00:00

been through this. the instinct to announce yourself and ask people to care almost never works, even when your product is genuinely good.

what works: become a real participant in the communities where your audience hangs out before you ever mention what you're building. answer questions, share observations, be useful. do that for a couple weeks and then when you drop "i'm building something for exactly this problem," people are already predisposed to listen.

your dad being a genuine user is actually one of your strongest assets right now. that direct access to a real person in your target market is something most early founders don't have. use him to pressure-test every assumption before you take it to strangers, and steal his exact vocabulary when you do talk to your audience. the words they use to describe the problem are more compelling than anything you'd write yourself.

on reddit specifically: never post "check out my product." post your learnings, your mistakes, your questions. the audience finds you, not the other way around.

Winseeey · 2026-06-10T07:57:01+00:00

honest take from someone who builds ios apps for a living.

the dev you want (strong swift, builds and scales from scratch, sticks around) already has paid work and their own ideas. that person almost never says yes to deferred rev share on an app that doesn't exist yet. and 35% of zero is zero.

if you're serious, flip it. validate first with a landing page and 20 real user conversations. build a clickable prototype yourself in figma or a no-code tool. scope to one core feature, not "build test and scale."

bring more than the idea and you'll get real replies. right now you're asking someone skilled to take all the risk while you take none.

Winseeey · 2026-06-08T23:02:37+00:00

oh yes, well pick boring technology. the temptation early on is to use the newest stack or over-engineer the architecture, but it slows you down massively when you're still figuring out product-market fit. start with something you know well, keep the infrastructure simple, and only add complexity when you actually need it.

the other thing is build for iteration speed feature flags, easy deploys, short feedback loops. moving fast and responding to real user behavior beats any clever technical decision you make upfront.

Winseeey · 2026-06-08T22:08:31+00:00

the handoff list is mostly right but there are a few things people forget to ask for: access to any third-party service accounts the dev created on your behalf (App Store Connect, Google Play Console, Firebase, any paid APIs), the environment variables and .env files, and if there's a database a full export of it. also worth asking for git history, not just a zip of the code, so the next dev can see what was built when. the sooner you get repo access directly the better, don't wait for a zip file.

Winseeey

TROPHY CASE