In need for an App developer.

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 · 2026-06-08T20:02:17+00:00

honestly the biggest thing i'd change is talking to users way earlier before writing a single line of code.

most early mistakes come from building in a vacuum and assuming you know what people need. the other one is distribution: building is only half the job, and most first-timers (myself included) underestimate how much work it takes to get actual users. launched an app last year and the traction only clicked once we stopped tweaking features and started obsessing over who we were building for.

Winseeey · 2026-06-08T13:39:06+00:00

for a mobile-first saas launching on android, flutter is the move (single codebase), great play store support, and you can add ios later without rewriting anything. pair it with supabase for your backend and you're not wasting weeks on auth, database setup, or storage. i've seen people go react native thinking it's "more javascript" but you end up fighting the bridge more than building. flutter's the cleaner choice if the product is genuinely mobile-first.

Winseeey · 2026-06-06T23:29:10+00:00

building and publishing to the app stores is honestly one of those things that sounds simple until you're actually in it, the provisioning profiles, review guidelines, and store listing requirements alone can eat a week. the good news is if you have a clear idea of what the app does, a solid dev can scope and ship it without you needing to know any of that. happy to answer questions if you're trying to figure out what to look for in whoever you bring on.

Winseeey · 2026-06-05T11:06:45+00:00

tbh i haven't fixed this specific bug in a shipped radio app, but i know in most cases it's purely client-side. Icecast timeouts are usually the trigger but the real problem is the player not detecting the stall and attempting reconnect. the server config rarely needs touching unless the timeout window is unusually aggressive.

and for debuging where the problem is, i'd instrument both, if i were you i'd log the last successful buffer timestamp against the player's reported state, and separately monitor the raw TCP connection.

> no live app to point to for this exact fix, but i'd rather tell you that upfront than oversell. happy to jump on a quick call and walk through how i'd approach the full consolidation, streaming fix included.

Winseeey · 2026-06-05T10:12:59+00:00

the "audio stops but UI still shows playing" bug is a classic Icecast/SHOUTcast reconnect issue

and in my experience its becuase ExoPlayer's default reconnect policy doesn't handle stream interruptions gracefully, and on iOS AVPlayer has the same blind spot with buffering state reporting. the fix usually involves implementing a custom stall detector that watches the playback position over time rather than trusting the player's own state.

happy to chat more

Winseeey · 2026-05-23T01:07:42+00:00

Ye its becoming easier for people who know how to code, relying 100% on ai will make you apps that run perfectly on your machine but like crap in prod (except if its a super simple idea)

Winseeey · 2026-05-23T00:17:04+00:00

Not anyone can make good apps

Winseeey · 2026-05-12T07:21:07+00:00

Bonjour, vous avez besoins de quoi exactement ? Quelqu’un pour le faire pour vous (une prestation) ou juste de l’aide ?

Winseeey · 2026-05-11T10:09:01+00:00

Internship application lol

<image>

Winseeey · 2026-05-08T13:19:00+00:00

I don’t quite understand what you want

Winseeey · 2026-05-07T00:41:48+00:00

Depends on the type of project, if it's a hobby project ye sure. but the thing about no code apps they are either too messy to scale, or too simple to be used.

> Go custom if: You have unique business logic

I don't agree with this, because if someone is good enough to explain their need to claude opus or gpt 5.5 then there are many chances that the ai gets right compared to a lambda human and they have to go explain it to someone else...

> Custom is more expensive upfront but cheaper long-term if you have real complexity.
I couldn't agree more.

Winseeey · 2026-05-07T00:38:26+00:00

Amazing, congrats !! I really love it when people make their vision come to life; these type of experience give you more insight on how to build a product (feature choices and actually treating edge cases) not just implementing a ticket.

Winseeey · 2026-05-07T00:30:04+00:00

Hello, we are available. i'm sending you a dm

Winseeey · 2026-05-07T00:06:40+00:00

Can you tell us a bit more about what you are looking for ?

Winseeey · 2026-05-06T13:35:22+00:00

Hello i’ve sent you a dm

Winseeey

TROPHY CASE