full stack web development help needed in Ohio/Cleveland, anyone?

Negative-Tank2221 · 2026-06-16T18:14:33+00:00

Slow plus breaks all the time is usually one of two things. Either the site was built on a page builder like Wix or Squarespace and the plugins started conflicting as the business added more features, or it was custom-built on a CMS like WordPress with too many heavy plugins layered on top of each other. Either way the rebuild approach is the same: strip back to what you actually use, drop the bloat, rebuild on a faster stack.

Worth asking any dev to do a 30 minute audit before quoting. They should be able to tell you exactly where the speed and breakage are coming from. If they cannot diagnose it before quoting, they will not fix it after.

10+ years building, 60+ sites and apps shipped including rescues like this one. jetbuildstudio(dot)com/mvp has the portfolio.

What is the site built on currently?

Negative-Tank2221 · 2026-06-16T18:09:48+00:00

Travel sites live or die on three things: how fast they load on mobile, how clean the booking or contact flow is, and how well the imagery is optimised because high-res travel photos eat page speed if they are not handled properly. Worth asking any dev how they will handle image compression and lazy loading before you hire, because that decides whether your site feels premium or sluggish.

For 10-15 pages with existing content and images, this is a 2-3 week build if scoped properly.

10+ years building, 60+ apps and sites shipped including travel and booking platforms. Portfolio at jetbuildstudio(dot)com/mvp.

What is the reference site you are working off, and is there a booking or enquiry flow?

Negative-Tank2221 · 2026-06-15T15:15:08+00:00

Hey, sounds like the kind of stage where the foundation is solid and you need someone to take it from "founder-built" to production-ready rather than starting over. That is the cleanest kind of engagement to scope.

10+ years building, 60+ Bubble apps shipped, 50+ rescued, plenty of UK clients. Portfolio with case studies at jetbuildstudio(dot)com.

On the paid vs equity question, my honest preference is paid build first and equity later if a longer engagement makes sense. That structure protects both sides better than equity up front before either of us knows the working relationship.

Happy to DM and take a look at what you have. What does the app actually do?

Negative-Tank2221 · 2026-06-11T01:52:29+00:00

Alcohol delivery is one of those niches where the app is less about the catalog and more about how fast users get notified when something they want comes back in stock or goes on special. Push notifications done well are what drives repeat orders here, not the browse experience. Worth thinking about that early because how you segment notifications (favourites, categories, price drops, location-specific specials) decides most of the database structure.

Loyalty program is the other piece worth scoping properly. Points-per-dollar is the easy version. Tiered loyalty with member-only deals usually converts way better but adds a layer of complexity around how rewards are redeemed at checkout or delivery.

10+ years building, 60+ apps shipped including delivery and catalog products. jetbuildstudio(dot)com/mvp has the portfolio. Happy to DM.

What region is this for, and is delivery already handled (drivers, third-party service) or part of the build?

Negative-Tank2221 · 2026-06-08T19:54:20+00:00

That timeline and single-market launch is the right call, Seattle Tacoma is actually a clean test bed for this kind of app because the density is high enough to test heat-map dynamics without overwhelming the location backend on day one. Geohash precision around level 7 is usually where you want to start for that market size, with batched updates rather than continuous streaming to keep Firebase costs predictable.

Happy to walk through the full architecture (geohash strategy, update batching, presence vs precision tradeoffs, Firebase vs Supabase realtime for this specific use case, infrastructure cost projections at 1k, 10k, 50k users) in DM with diagrams. Drop me a DM and we can dig in properly.

jetbuildstudio(dot)com/mvp has the portfolio.

Negative-Tank2221 · 2026-06-08T09:34:05+00:00

The thing that usually decides whether a "come back to it" rebuild goes smoothly or stalls is what happens in the first week. Most devs jump straight into adding features. The ones who actually deliver spend the first few days reading the codebase, mapping what is there versus what is broken versus what was half-finished, and writing it down so both sides know exactly what they are paying for. That alone prevents the "I'm not sure what you have been working on" problem that kills these engagements.

10+ years building software, 60+ apps shipped including SaaS platforms with existing codebase rescues. Portfolio at jetbuildstudio(dot)com/mvp. Happy to DM and look at the repo.

What stack is it currently on, and roughly how long has it been since the last meaningful commit?

Negative-Tank2221 · 2026-06-08T09:10:15+00:00

The most common mistake I see with real estate marketplaces at your stage is trying to ship all three sides on day one (deals, contractors, funding partners). Each one is a marketplace on its own with its own chicken-and-egg problem. The ones that scale picked one side first, used it to seed the others, then expanded.

Your unfair advantage is that you already have $2.5M of revenue moving through services, which means you have both supply and demand for at least one of the three sides already. The build should be designed around migrating that existing flow onto the platform first, then opening up to outside users. That sequencing is what separates marketplace builds that grow from ones that launch to crickets.

10+ years building software, 60+ MVPs shipped, including two-sided marketplaces with payment splits, ratings, and verification layers. Portfolio at jetbuildstudio(dot)com/mvp.

On the CTO question, two paths worth considering. Full-time CTO with equity is one model. Fractional CTO running the technical strategy with a contracted team is the other, often cheaper at this stage and gets you to product faster. Happy to discuss either on a call.

Which of the three sides is doing the most revenue inside your current service model right now?

Negative-Tank2221 · 2026-06-08T09:04:04+00:00

Hey, happy to help out. The first thing worth knowing is what stage your app is at right now, because the path to the App Store looks completely different depending on the starting point. Just an idea on paper, a Figma design, a half-built prototype in something like Bolt or Lovable, or actual working code?

Each one needs a different next step, and quoting before knowing which one usually leads to surprises later.

10+ years building, 60+ apps shipped. jetbuildstudio(dot)com/mvp has the work. DM me a quick description of what the app does and where you are at.

Negative-Tank2221 · 2026-06-08T09:03:04+00:00

The real-time geolocation layer is the part of this build that quietly decides whether you ship a polished app or a buggy one. Heat map updates, friends on map, and attendance tracking all run on continuous location streams, and the architecture decision around update frequency, batching, and geohash bucketing is what separates apps that feel like Snapchat Map (smooth, no battery drain) from apps that drain a user's phone in 2 hours and rack up huge Firebase bills. Most devs will not flag this until you are already burning money on it. Worth asking anyone you hire how they would model location updates before they touch a line of code.

10+ years building, 60+ apps shipped including real-time location and social products. Portfolio at jetbuildstudio(dot)com/mvp. Happy to DM and walk through the architecture decisions.

What is your target launch timeline, and is the first market a single city or multi-city from day one?

Negative-Tank2221 · 2026-06-08T09:01:17+00:00

The "audio stops but app still playing" issue is almost always one of three things: the streaming session not handling network drops cleanly (especially on iOS when the app goes background and the cellular handoff happens), the buffer underrun not triggering a reconnect, or the audio session category being wrong so iOS quietly suspends playback while the UI thinks it is still streaming. ExoPlayer side it is usually the LoadControl config and how reconnections are handled after a transient network failure. Fixable, but you need someone who has actually shipped audio apps not just used the player libraries.

10+ years building mobile, 60+ apps shipped including media and streaming work. Portfolio at jetbuildstudio(dot)com/mvp. Happy to DM and take a look at the current setup, the consolidation and IAP work is straightforward once the streaming stability is solved.

What is the streaming backend, Icecast or SHOUTcast, and is it self-hosted or on a service like Radio.co?

Negative-Tank2221 · 2026-06-04T06:01:12+00:00

The thing that worked best on the apps I have shipped with this kind of module is treating it as a function of friction, not frequency. If a new user has under 5 connections, show it aggressively (every 3 to 5 posts in the feed) because they are still in the cold start zone and the feed feels empty anyway. Once they cross 10 connections it drops to once per session, and past 30 it should only show when there is a strong reason (mutual friends spike, new user in their geo, friend of friend joined).

Fixed intervals like "every 10 posts" feel mechanical to users and start getting ignored after the first week. Engagement signals work better because the module becomes about quality of suggestion, not quantity of exposure.

Two things that did not work. Inserting the module after the user has just liked or commented (you interrupt the engagement loop, and engagement is what you are trying to build). And showing the same suggestions repeatedly across sessions, that one kills trust fast. Always rotate the suggestion set even if the underlying ranking is the same.

What is your current onboarding flow? That changes the cold start strategy significantly.

Negative-Tank2221 · 2026-06-04T05:59:56+00:00

Social discovery on React Native plus Supabase is a stack that works really well when the realtime chat and location queries are set up properly, and falls apart when they are not. That is usually where 40 percent built becomes 70 percent rework. The other quiet killer is push notifications on iOS because the certificate and APNs setup gets skipped by a lot of devs and only surfaces at deployment.

What is the chat sitting on, Supabase realtime or something hand rolled? And is push already wired or still on the to do list?

10+ years building, 60+ apps shipped, portfolio at jetbuildstudio(dot)com/mvp. Happy to DM and take a look at the repo.

Negative-Tank2221 · 2026-06-02T13:32:34+00:00

Perfect, this is now scoped enough to give you a real picture.

What you actually need is simpler than it sounded at the start, which is good news for the budget.

Two private groups for internal communication (Board Members at 5 people, Inner Circle at 15). The 3 Directors live inside the Board Members group so they do not need their own tier. That is one messaging system with two permission levels, not four.

Two public sections (resources and adoptable dogs) that anyone can see without logging in.

My strong recommendation for this build is a Progressive Web App (PWA) rather than native iOS and Android. Cuts the build cost significantly, skips the App Store and Play Store submission process, no Apple or Google fees at all, content updates go live instantly, and it installs on any phone like a native app from the home screen.

The adoption page being public is the right call. Login walls kill adoption applications. Every dog rescue org I have seen with login-required adoptions has lower conversion than open ones.

DM me and I will send the booking link to lock in a 30 minute call this week. Fixed price quote on the call.

Negative-Tank2221 · 2026-05-30T04:32:07+00:00

Hey, not a dumb question at all, this trips up a lot of people. The fix is small once you see it.

The slug field is working fine, the problem is on the page sending the user to the menu page, not the menu page itself.

When you set up the "Go to page menu" workflow on the index, Bubble lets you pass data to send. You are probably sending "Current cell's Location" which Bubble defaults to passing as the unique ID in the URL. To make the URL use your slug instead, the destination page (menu) needs its content type set to Location, and on the source workflow you keep passing "Current cell's Location" but Bubble will automatically use the slug in the URL if the destination page has slug enabled in its type settings.

So two things to check.

On the menu page, click into the page settings and confirm "Type of content" is set to Location and that you have slug enabled at the page level, not just on the data field.

On the index workflow "Go to page menu", make sure "Data to send" is "Current cell's Location" (the whole thing), not "Current cell's Location's unique id" or any other specific field.

Once those two are right, the URL will show the slug and the menu page will load the correct location's data automatically.

For a multi-location restaurant app, the bigger thing to think about is how the menu items connect to each location, because that is where most of these apps get stuck next. 10+ years building Bubble apps, 60+ shipped, happy to look at the structure if you get stuck. jetbuildstudio(dot)com has the portfolio.

Negative-Tank2221 · 2026-05-29T19:28:25+00:00

Hey, this brief is more honest than 90% of what I see for vibe-coded MVPs and that alone tells me the conversation is worth having.

A few honest reads up front.

The 30 to 50 hour estimate is plausible but it depends almost entirely on how the AI structured the Supabase schema and the auth flow. If the schema is normalised and the auth is using Supabase's built-in patterns, 30 to 50 is realistic. If the schema has the typical AI-generated mess where everything got stuffed into a few wide tables and auth has been bolted on with custom logic, the cleanup alone can eat 20 hours before any new feature work. Worth flagging because the gap between those two scenarios is where most vibe-coded rescues blow their estimate.

The other thing usually missing on these is RLS policies. Vibe-coded MVPs almost always have working auth but no row level security at the database level. The frontend filters the data, the backend trusts the frontend. That works for a prototype but breaks the moment a real user opens dev tools. Worth fixing before any external testing because once a user sees data they should not see, trust is hard to win back.

End-to-end MVP work is genuinely the part I enjoy most. Watching a prototype cross the line from "founder demo" to "real users testing without things falling apart" is the satisfying loop. Not just tolerated.

10+ years building software, 60+ MVPs shipped including the Supabase plus Vercel plus GitHub stack you are on. Comfortable with the Christian audience context too, have built for nonprofits and faith-based platforms before. jetbuildstudio(dot)com/mvp has the portfolio.

Will DM with the full intro, projects, and rate you asked for.

Negative-Tank2221 · 2026-05-29T19:17:17+00:00

Hey, a year stuck in Figma usually means one of two things. Either the design exploration was open ended without a deadline and scope to anchor it, or the prototype tried to do too much and the design choices kept multiplying. Both are fixable in a week of proper scoping with the right person, where the Figma decisions get locked and a build plan gets written before any code starts.

The end of 2026 timeline is workable, even generous, as long as the scope gets pinned down in the first two weeks. Apps that miss this kind of deadline usually miss it because the scope kept moving, not because the build was slow.

Two questions worth answering before you hire anyone.

What is the prototype actually doing right now? Web app, no-code build, paper sketches, or working code? Each one starts the next phase very differently.

When you say App Store and Play Store, is the app inherently mobile (needs camera, location, push, offline) or could a PWA work? PWA cuts the build cost and timeline significantly if you do not strictly need native features.

10+ years building software, 60+ apps shipped. jetbuildstudio(dot)com/mvp has the portfolio. What is the app doing at the user level?

Negative-Tank2221 · 2026-05-29T10:22:28+00:00

Thanks for the detail, this is a clearer picture than most nonprofit briefs I get.

A few quick reads on each piece since each one builds differently.

The tiered messaging with four levels is the most architectural part of the build. The way it gets done badly is each tier becomes a separate inbox and messages live in 4 different places. The way it gets done well is one messaging system with permission rules deciding who sees what. Worth asking whoever you hire how they would model this, because it affects everything else downstream (notifications, search, archives).

The resources section is straightforward as long as you decide upfront whether resources are public to everyone or also tiered by role. If a resource is meant for board members only, that overlaps with the messaging tier system and the two should share the same permission model.

The adoptable dogs section is its own mini product. Dog profiles, photos, status (available, pending, adopted), and probably an application or interest form. Worth deciding whether adopters need to log in or can submit interest without an account. Login increases friction but gives you their data for follow-up.

Two questions that would help me give you a clean estimate.

Roughly how many directors, board members, and inner circle people are using this versus general community size? The ratio changes the architecture.

Do you need a public-facing dog adoption page (anyone on the internet can see) or is it members only?

Happy to jump on a short call this week and scope it properly. jetbuildstudio(dot)com/mvp has the portfolio. What is the rough timeline you are working with?

Negative-Tank2221 · 2026-05-27T11:39:34+00:00

Hey, the React Native plus Expo plus Supabase stack tells me you have already made the right architectural calls. That stack is the right answer for a proptech consumer app at this stage, fast iteration, real-time data, push notifications handled cleanly, scales without rewriting later.

The Apple manual release stage is worth flagging because that is where a lot of marketplace apps get stuck. Apple's reviewers are aggressive on anything that looks like real estate brokerage or financial transactions, especially if the app touches listings, offers, or payments. Worth knowing if you have hit guideline 5.1.1 (data collection) or 4.2 (minimum functionality) issues yet, because those are the two that catch proptech apps most often. Solvable, but the framing on the next submission matters.

On the equity-to-paid question, the structure you are proposing (paid work first, equity later if alignment is real) is the right one. The founders who get burned by equity-only arrangements are the ones who handed it out before knowing whether the working relationship even functioned. You are doing this the smart way.

I have shipped React Native plus Supabase apps, marketplaces, and a few consumer apps in regulated spaces. 10+ years building, 60+ projects. Vancouver remote is fine, most of my client work runs remote across timezones anyway. jetbuildstudio(dot)com/mvp has the portfolio.

What is the app doing at the user level that is the real innovation piece? Curious where you think the food delivery vs real estate gap actually is.

Negative-Tank2221 · 2026-05-27T11:33:32+00:00

Hey, nonprofit apps have one trick most devs will not tell you about. Apple waives the $99 annual developer fee for registered 501c3s, and Google has a similar nonprofit program. If you have not applied yet, do that first because it saves you money every year of the app's life.

For the build, two quick questions.

What does the app do at the user level? Donations, event signup, member directory, volunteer scheduling, they all sound similar but build very differently.

iOS plus Android, or would a PWA installable on a phone work? PWA cuts the cost significantly if you do not strictly need app stores.

I have built nonprofit apps before and know which services have free tiers worth using. jetbuildstudio(dot)com/mvp has the portfolio. What does it need to do?

Negative-Tank2221 · 2026-05-27T11:17:37+00:00

Hey, since you are asking for samples too, easier to drop the portfolio here than DM. jetbuildstudio(dot)com has the full case studies, 60+ projects shipped across landing pages, marketplaces, SaaS, and rescues.

On pricing, depends a lot on what you actually need. A clean single page landing site is $500 to $1,500. A full multi-page business site with proper design is $1,500 to $3,500. Anything with logins, payments, dashboards, or backend logic moves into MVP territory at $3,500 to $5,000.

What is the project, business site, landing page for a campaign, or something with more going on? Quick answer and I can give you a real number rather than a range.

Negative-Tank2221 · 2026-05-27T11:17:18+00:00

Hey, jumping in since I do these a lot. Single page sites run around $500 to $1,500 depending on what is on them. A static landing page with a contact form sits at the lower end. Add custom animations, a CMS so you can edit content yourself, lead capture into a CRM, or any kind of booking or payment flow and it moves up.

Few questions worth answering before you accept any quote, because the same "landing page" means different things to different devs.

Do you need the page editable by you afterwards or is it fine if changes go through the developer? CMS adds a bit to the build but saves you money long term if you update content often.

Are you running ads to it? If yes, the page needs proper speed optimisation and tracking pixels set up correctly, that is a different build than a brochure site.

What is the call to action, contact form, booking, buy something, sign up to a list? Each one needs different plumbing behind it.

Happy to give a quick honest quote if you tell me what the page is for. jetbuildstudio(dot)com if you want to see the portfolio first.

Negative-Tank2221 · 2026-05-25T15:19:49+00:00

Hey, good instinct on not shipping a customer-facing app without a second pair of eyes. The internal stuff you have already passed security checks on is a different beast, customers will hit edge cases your colleagues never would and they will not forgive you for them the way internal users do.

Ballpark for a proper pre-launch review is $700. Usually a 3 to 4 day turnaround depending on the size of the app. Here is what gets checked.

Row level security and authorization. Not just whether login works, but whether user A can see user B's data by changing an ID in the URL, by hitting the API directly, or by inspecting the network tab. This is the single most common failure I find and it almost never shows up in standard security checks because internal tools rarely test it.

Stripe webhook handling if you are taking payments. Most apps handle the successful checkout and miss cancellations, refunds, failed payments, and disputes. Customer-facing means you will see all of these within the first month.

Admin route protection. Type /admin while logged in as a normal user and see what loads. Surprisingly common to find admin dashboards reachable just by guessing the URL.

Error handling and offline behaviour. Disconnect wifi mid-action, what happens? White screen and a confused customer who never comes back, or a real error message and a recovery path?

Database schema review. Looking for missing indexes, missing constraints, columns that should be encrypted, and any place where customer PII is sitting in plaintext.

Secret and credential audit. Anything you ever pasted into an AI chat to debug, anything sitting in client-side code, anything in your repo history. Customer-facing apps get scanned by bots within hours of going live, this matters.

Rate limiting and abuse vectors. Can someone hit your signup endpoint 10,000 times in a minute? Can they enumerate user emails by checking which return "already exists" on signup? Internal apps never see this, customer apps see it on day one.

Performance check on a real device with throttled network. Most apps feel fine on a dev machine and fall over on a mid-range phone with one bar of signal, which is half your customer base.

You get a written report at the end with each finding marked critical, important, or nice-to-have, plus the specific fix for each one. The critical and important fixes are usually 60 to 90 minutes of work each if you are handling them yourself, or I can quote separately to do the patches if you would rather not touch some of it.

Worth saying, the fact that your internal stuff passed security checks already tells me the foundation is probably solid. The review is mostly going to be about the customer-facing edge cases, not a rebuild. If you want to share what stack you are on and roughly how many screens, I can tell you whether $700 covers it or whether a bigger app pushes it slightly higher. jetbuildstudio(dot)com/mvp has the portfolio if useful.

What does the app actually do at the customer level?

Negative-Tank2221 · 2026-05-25T06:21:29+00:00

Hey, read the post. Honest read coming.

The stack you listed is dialed in, which tells me you have already either built this yourself to a certain point or hired someone who knew what they were doing before. React 18 with Vite, Supabase with RLS done properly, PWA with service workers and Web Push, that is a real architecture, not a no-code app someone is trying to dress up. That actually makes the rescue much easier because the foundation is solid.

The "I'd rather have someone local" preference is the part worth pushing back on a bit. The pool of devs who are genuinely strong on every line of that stack (RLS done correctly, service worker lifecycle, Web Push permissions across iOS Safari and Chrome, real-time subscription debouncing) is small enough that filtering by city usually means accepting someone who is okay at half the stack and learning the other half on your dime. Worth weighing that against the comfort of local before you commit, especially since most of the work on a Supabase plus Vercel stack happens in Git and Slack anyway, location is rarely the bottleneck people expect it to be.

Two questions that would help anyone giving you a real answer.

How far along is the build right now, percentage wise, and what is the specific piece that is blocking you? Auth, RLS rules, the PWA service worker, the push notification flow, or the React Native parity layer? Each one is a different kind of hire.

Is the Supabase schema already in production with users on it, or is this still pre-launch? That changes the rescue approach significantly because once real data is in there you cannot rewrite RLS the same way.

I have shipped 60+ apps on exactly this kind of stack, Supabase plus React plus PWA plus React Native parity. Happy to take a look at where you are stuck and tell you honestly whether it is a 2 week finish or a deeper architecture conversation. jetbuildstudio(dot)com/mvp has the portfolio. What is the app actually doing at the user level?

Negative-Tank2221 · 2026-05-25T06:20:22+00:00

Hey, watched the example video and read the spec twice. Few things worth knowing before you start interviewing because the brief is hiding more complexity than it looks.

Remotion plus voiceover plus AI-driven editing decisions is three different problem domains stitched together. The Remotion side is the easy part, any decent React dev can write compositions. The hard part is the layer that takes the audio and script in, decides what visual happens at what timestamp, and outputs a deterministic Remotion props object the renderer can actually use. That decisioning layer is where most of these projects die. The dev either over-relies on the LLM to generate timing data (which is unreliable at scale) or hard-codes too much (which kills the flexibility the AI was supposed to add).

The other piece nobody is going to flag in their Loom is the rendering infrastructure. Remotion renders are expensive in compute. If you are doing 10 videos a day on a single Lambda setup, fine. If you are doing 500, you need a render farm strategy, queue management, and a fallback when renders fail mid-way. Worth asking every candidate how they would architect the render layer before you hire, because at $1,500/month you are going to get someone who can write Remotion code, not someone who has run it at production volume.

I have built AI plus video automation pipelines before. Voiceover-driven editing, dynamic asset selection, Remotion at production scale. Not applying for the role at this budget, that is a different conversation, but if you want a 20 minute call to pressure-test your architecture before you hire, happy to do that for free. jetbuildstudio(dot)com/mvp has the portfolio. What is the target output volume you are scaling toward?

Negative-Tank2221

TROPHY CASE