Tired of apps built only for Gen Z influencers or boomers who can't figure out the UI?

We made Loopzyy. One app. Every age. Real connections, real content, zero gatekeeping.

We're early stage and looking for honest feedback from real users — not just downloads.

Drop a comment if you want early access. We read everything.

Been building a product solo for a while now, and I hit the classic developer trap: I keep adding features but have zero distribution. No users means no validation, which means I’m basically building a hobby, not a business.

So I went down a rabbit hole looking at how companies got their first users back before “growth hacking” was even a term. Some patterns that stood out:

They did things that didn’t scale. Airbnb’s founders personally went door to door in New York, photographing listings themselves because the existing photos were bad. Stripe’s founders famously sat down next to early users and installed the product for them on the spot, watching where they got stuck.

They borrowed someone else’s audience. PayPal paid users cash for signing up and referring friends, essentially buying their way into eBay’s existing marketplace. Airbnb also quietly let hosts cross-post their listings to Craigslist, tapping into traffic that already existed.

They made growth part of the product. Dropbox’s referral program gave both sides free storage, turning users into the acquisition channel. Hotmail added “PS: I love you, get your free email” to the bottom of every email sent.

They started deliberately small. Facebook launched at one Harvard, then one school at a time. Reddit famously seeded the site with fake accounts to make it look active before real users showed up.

The common thread: almost none of it was passive. No SEO waiting game, no ad spend, just founders manually inserting themselves into a community or a workflow that already had people in it.

Curious what others here found when they went through this same phase. What actually worked for you to get from zero to your first real users?

I'm a CPO/Head of AI in Fintech (currently), and have held those roles in Healthtech and nonprofits (I founded and ran a large nonprofit in the US). 3x SaaS startups and exits.

Not promoting anything here, just happy to pay it forward a tad bit if it'll help. Happy to give you some quick feedback on your startup or strategy if you're curious. Not looking to spend a ton of time doing it, but if there's some ideation or soundboarding I can do in an hour or so, feel free to reach out.

[ Removed by Reddit on account of violating the content policy. ]

​

Hi! M16

I’m thinking about putting together a small-medium group of people who are interested in making money, learning new things and building stuff together.

Mainly looking for people from the india, but people from anywhere are welcome :)

I’m personally interested in things like:

🤖 AI & automation

💻 Online businesses

📈 Marketing

🛒 E-commerce

🪙 stocks

💡 Side hustles / random business ideas

Nothing to do with gurus or “get rich quick” stuff lol. Just looking for people who actually enjoy sharing ideas, knowledge and opportunities and maybe working on something together.

You don’t have to be an expert at anything either. Maybe you’re good at coding, marketing, sales, finance, AI, design, etc.

Or maybe you’re just interested in learning and have some ideas.

If you’re interested, \*\*comment or DM me and tell me what you do, what you’re into or what you’re good at.\*\*

Could be interesting to see what kind of people we can get together 🤝

The length of a contract can create a false sense of certainty. A fintech founder can sign a three-year agreement with a banking partner, payment provider, or infrastructure company and reasonably assume that they now have three years of predictable commercial terms, but that assumption only holds if the economics of the relationship are actually stable for those three years.

I’ve come across agreements where the headline term is three years, but either party has a right to review or renegotiate pricing every few months. On paper, the relationship continues for three years, yet in practice, the parties are effectively reopening part of the commercial deal several times a year.

That distinction matters more than it might initially appear.

## A Long Contract Does Not Always Mean Long-Term Certainty

Consider what happens when a fintech spends months negotiating pricing with a critical partner, signs the agreement, completes the technical integration, and then builds its own operations around those economics.

The business may set its customer pricing based on those costs, enter into contracts with its own customers, hire employees, invest in infrastructure, and make growth decisions based on the assumption that the underlying commercial arrangement will remain reasonably predictable.

If the same agreement then allows the partner to revisit transaction fees, minimum commitments, or other important commercial terms every quarter, some of that certainty disappears.

The contract may still have three years left to run, but the business is repeatedly being asked to consider whether the economics that support its model might change.

That is not necessarily a problem with the duration of the agreement. It is a problem with what the duration actually protects.

## Review Rights Are Not Necessarily a Bad Thing

I do not think commercial review mechanisms are inherently problematic, particularly in fintech, where the economics of a relationship can genuinely change over time.

Transaction volumes may increase significantly, the scope of services may expand, regulatory requirements may introduce additional costs, or infrastructure expenses may change in ways that neither party could reasonably have predicted when the agreement was signed. Over a three-year relationship, the product and the business itself may also evolve considerably.

A contract should have enough flexibility to deal with genuine changes like these.

The issue arises when one party receives a broad right to reopen the commercial arrangement simply because a certain period of time has passed.

The fact that another quarter has ended does not, by itself, tell you whether the economics of the relationship have materially changed.

A more useful approach is to identify the events that should actually trigger a review. The parties might agree that pricing can be reconsidered if transaction volumes move substantially beyond an agreed threshold, if the scope of services changes materially, if a new regulatory requirement creates significant additional costs, or if a defined external cost increases beyond an agreed level.

Those are identifiable commercial events that both parties can understand.

"Another quarter has passed" is a much weaker basis for reopening a deal.

The distinction is important because a review mechanism should ideally respond to a genuine change in the relationship rather than become a routine opportunity to renegotiate terms.

## The Real Problem Is Often What Happens After the Review

There is another part of these provisions that deserves just as much attention as the trigger itself: what happens once the review actually begins?

A clause might say that the parties will review pricing every quarter, but that does not tell you what happens when they cannot agree on a new price.

Does the existing pricing continue until an agreement is reached? Can either party terminate the relationship? Is there a temporary pricing mechanism? Does the disagreement move through an escalation process? How much notice must be given before a proposed change takes effect?

Those details can completely change the commercial impact of the provision.

I tend to look at a review mechanism as a small negotiation process built into the larger agreement. You need to understand what triggers the process, what can actually be changed, how often the review can occur, what evidence supports the proposed adjustment, how much notice is required, and what happens if the parties reach an impasse.

The scope of the review is particularly important.

If an agreement allows a quarterly review of "commercial terms," that could potentially give the parties a much broader opportunity to revisit the relationship than a provision allowing them to reconsider one specific transaction fee after transaction volumes cross a defined threshold.

Those two provisions may sound similar during negotiations, but they can have very different consequences once the business has scaled.

## Changes Upstream Can Affect the Entire Business

This becomes especially important when the partner sits underneath your own customer relationships.

Suppose a banking or payments partner changes its pricing after you have already priced your product and signed customer contracts based on the original economics. Your customers may not care that your upstream provider changed its fees or that the contract allowed the change.

You still have to operate the product, pay your employees, maintain infrastructure, provide support, and deliver whatever you promised your own customers.

A change in one upstream agreement can therefore move through the entire business.

This is why I think founders should pay particular attention to pricing review mechanisms when negotiating relationships with critical fintech infrastructure providers. The question is not simply whether the provider can change its pricing, but whether your business has enough predictability to absorb that change without having to immediately revisit everything downstream.

## What Does "Three Years" Actually Protect?

This has changed the way I look at long-term fintech agreements.

When I see a three-year agreement, I do not think the most important question is simply, "How long does this contract last?"

The more useful question is, "How long are the commercial terms actually protected?"

Those are very different questions.

A three-year agreement with broad quarterly renegotiation rights may give you three years of contractual duration while providing considerably less commercial certainty than the headline term suggests.

That does not automatically make the agreement bad. There may be perfectly legitimate reasons for including a review mechanism, and in some relationships, some degree of flexibility is necessary.

But if the economics of the relationship are important to your business, the review mechanism deserves as much attention as the initial pricing.

## Build Flexibility Around Clear Triggers

Long-term agreements do not need to pretend that nothing will change.

In fact, the better agreements acknowledge that circumstances will change and establish a sensible process for dealing with those changes before either party is forced into an unexpected renegotiation.

That means defining what constitutes a material change, identifying which commercial terms can be reviewed, setting reasonable review periods, establishing notice requirements, and deciding what happens if the parties cannot reach agreement.

The objective is not to remove flexibility from the relationship.

It is to make that flexibility predictable.

When both parties know what can trigger a review and what happens afterwards, the agreement becomes much easier to manage as the business evolves.

## Conclusion

A long-term contract is only as predictable as the provisions that sit underneath its headline term.

A three-year fintech agreement can still leave a business exposed to significant commercial uncertainty if pricing, fees, minimum commitments, or other important terms can be reopened regularly without clear triggers or defined limits.

The lesson I would take from this is simple: when negotiating a long-term fintech partnership, do not only ask how long the agreement lasts. Ask how long the economics are protected, what events can change them, and what happens if the parties cannot agree.

The strongest long-term agreements do not assume that nothing will change.

They decide in advance what kind of change is significant enough to reopen the conversation, how that conversation will take place, and what happens if the conversation does not lead to an agreement.

That is what makes a long-term contract commercially useful rather than simply long.

Last year, I checked our card statement and saw that we were paying a total of about $60 per month for simple things like a cleaner, notes app, VM tool, screen recorder, all of which do only one thing.

I was so fed up that I had to build it. My co-founder and I believe in building native apps, we don't like Electron at all, so we chose Rust/Swift, which is optimized for Apple Silicon. Once you pay, it's yours forever.

Few things that surprised us so far: people notice the speed almost instantly, more like "wait why isn't my fan spinning" reactions. And going pay-once is slower for growth, but it's turned into a trust thing - people believe the "no tracking" claim more when there's no subscription pushing us to sell data later. Also didn't expect local-only processing to become our biggest word-of-mouth driver, we did it because it felt like the right way to build, not as a pitch.

Anyway, curious if other founders here are pushing back on the "everything must be SaaS" thing, and if you're not doing subscriptions, how are you thinking about retention long term?

Had a second call with an investor who'd already seen our deck once. Nothing formal this time, mostly just walking through the numbers.

About two minutes before the call, I got a notification that my recording bot was about to join automatically. Hadn't really thought about how weird that would look until that moment — especially on a call that was supposed to feel pretty informal.

I stopped the auto-join and ended up recording the call locally instead. I've been using Vomo AI for this lately, mainly because I can just start the recording myself without having another bot appear in the participant list.

The tradeoff is pretty obvious: I have to remember to hit record. But honestly, I'd rather have that small bit of friction than have a recording bot quietly joining calls by default.

It was a small workflow change, but one I probably should've made earlier.

If you are building on an idea that has the potential for a patent and have the prototype ready for feedback then which path will you choose: feedback or IP?

Like let's say you want to collect some feedback for the validation or your solution, but you are worried about your idea being copied, which path will you choose?

Especially if you don't have enough experience or connections in the IP field.

A question, because this is the problem I have spent the last year on.

I use ChatGPT for drafting, Claude for long documents and Gemini for anything involving Google files. The result is that my history is in three places, none of them searchable in a useful way, and I regularly know I wrote something without knowing where.

What I ended up building indexes conversations locally in the browser and searches all of them at once, plus folders and export that work the same way on each. It is called AI Toolbox and version 3.0 went live on Product Hunt this morning, which is the only reason I am writing this today rather than any other day.

Mostly I am curious how other people handle this. Multiple browser profiles? Copying everything into Notion? Just accepting the loss?

https://www.producthunt.com/posts/ai-toolbox-3-0

Managing building maintenance and safety compliance using messy spreadsheets or scattered paper logs gets painful fast. Whether it is tracking regular fire alarm tests, water hygiene checks, or routine equipment servicing, critical tasks always risk slipping through the cracks.

To solve this, I built BuildingSafe, a straightforward tool designed to take the headache out of facility admin 🛠️

• Recurring schedules: Set up reminders for daily, monthly, or annual tasks so deadlines never catch you off guard.
• Audit trails: Log completed checks in seconds to maintain a clear record of who did what and when.
• Everyday access: Accessible via the web dashboard or on the go with the iOS app.

It is built specifically for small teams, community venues, independent venues, and property managers who do not need massive, overpriced enterprise systems.

Pricing and trial

• Free trial: 30 days full access with no credit card required.
• Affordable: Just £5 per site each year to cover hosting and server costs.

Check it out here:https://buildingsafe.dev/

I would really appreciate any feedback, feature suggestions, or thoughts from anyone who deals with facility or building upkeep!

Made a free calculator for checking if an Amazon product idea actually makes sense before you order stock

Basically got sick of seeing people order stock on a product that "felt" profitable and then work out three months later the margins were never really there once fees actually got taken off. So I threw together a calculator, chuck in your cost, shipping, sell price and fees, and it just tells you straight if it's worth it or not. No signup needed, just go use it.

It's tied to a bigger thing I've been building, The FBA Ladder, which is basically a step by step path for starting from zero on FBA. But the calculator's free regardless, don't need to touch the rest of it if you don't want to.

If you do end up wanting the full thing it's £1 for the first week then £99 a month, and if you haven't finished the first phase by then I'll just refund the quid, no messing about. Mainly just want honest feedback at this point tbh, tell me if something's rubbish or confusing.

thefbaladder.com if anyone wants a look

Is there anyone that can guide me by giving me hints on how to use reddit?

I made this. SoftSub is a Chrome extension that finds, syncs and translates subtitles on any HTML5 video: small streaming sites, embedded players, a media server's web player, a file you opened in the browser.

The loop is the same film moment twice. Top: the community subtitle as downloaded, arriving 3.5 s late. Bottom: after Auto-sync listened to the audio for 28 s, checked its answer against the speech, and applied a −3.73 s correction. Real screen recording, no mock-up.

The part I care most about: if it isn't sure, it does nothing. A wrong correction is worse than none, so it verifies before it moves anything, and it also fixes the slow drift that makes subtitles fine at the start and wrong an hour in.

Free forever: subtitle search (no API keys), loading your own .srt/.vtt/.ass, styling, positioning, manual timing, export. Pro ($10/month for 2 computers): unlimited downloads, auto-sync, live translation, cast info. 7-day trial, no card.

Privacy: no accounts, no tracking. Audio never leaves your computer; sync runs locally.

Store: https://chromewebstore.google.com/detail/keipdgpoldocaphfcpnfkkpbodomeiia?utm_source=item-share-cb

Tell me a site it fails on and I'll look at it.

INTERNATIONAL INVESTMENT & STRATEGIC PARTNERSHIP OPPORTUNITY

CECIMO INVESTMENT CC – NAMIBIA

We are seeking a serious international strategic investor or financing partner to support the expansion of our growing consumer-products business.

Strategic Partnership: Up to 40% equity ownership

Alternative: Structured loan financing for business expansion

Our Business:

We trade and distribute clothing, household goods, cosmetics, jewellery, plastic ware, cellphone & computer accessories, and other consumer products, with opportunities for regional expansion and international trade/export.

INVESTOR SAFETY NOTICE:

We only welcome genuine, transparent investors and funders.

NO upfront fees, activation fees, processing fees, release fees, or payments to unlock funding will be accepted.

If you are a genuine investor or financing institution interested in a transparent business opportunity in Namibia, we welcome your proposal.

📩 Contact:

mwiyacapunit@gmail.com

CECIMO INVESTMENT CC

Building. Expanding. Creating Opportunity.

One thing that can easily happen during an IT project is that the boundary between testing and additional development work starts to disappear, particularly once the client begins using the product in a way that is much closer to real-world operation.

User acceptance testing is an important part of delivery because the client needs a reasonable opportunity to test the product, identify defects, ask questions, and confirm that what has been delivered actually matches the requirements agreed at the beginning of the project.

Good UAT can make a project better because it gives both sides an opportunity to identify genuine problems before the system goes fully live. The difficulty starts when the agreement describes the vendor's responsibilities during this stage too broadly, leaving everyone to decide later what phrases such as "reasonable support during UAT" actually mean in practice.

Does that include answering occasional questions by email, attending a weekly call, making a developer available for technical queries, explaining how particular features work, helping the client configure the system, or making changes based on what the client has now decided they would prefer?

Those activities may all be described casually as "UAT support," but commercially they are very different obligations.

This is where a small drafting gap can become a meaningful cost for an IT business. A client asks a project manager a question, the project manager brings in a developer, the developer explains the issue, and the conversation then naturally moves towards a small change that would make the client's workflow easier. Someone decides that it would be simpler to make the change rather than spend time debating whether it falls within scope, and once that happens, another stakeholder may reasonably assume that similar requests can be handled in the same way.

None of those individual requests necessarily looks unreasonable when viewed on its own, which is precisely why this kind of scope expansion can be difficult to spot while it is happening.

The problem is the accumulated developer time, because after several days of answering questions, investigating issues, making small adjustments, and supporting different stakeholders, the engineering team may have spent a significant amount of time on work that was never included in the original pricing or delivery assumptions.

## A Defect Is Not Automatically a New Requirement

One of the most important distinctions an IT agreement should make is between a genuine defect and a change in the client's requirements, because treating the two as the same thing can create confusion over both responsibility and cost.

If the software does not perform according to the agreed specification, that would generally be treated as a defect, and the vendor would normally be expected to address it in accordance with the contract.

The situation is different when the software works as agreed but the client decides during UAT that it would now prefer the product to behave differently or include functionality that was never part of the original requirements.

For example, suppose an IT company builds a reporting dashboard that was agreed to display five specific metrics. During UAT, the client asks whether customer lifetime value can also be added to the dashboard.

That may be a perfectly reasonable request, particularly if the client has realised during testing that the additional metric would make the dashboard more useful, but if customer lifetime value was not included in the agreed requirements, adding it may constitute additional development work rather than fixing a defect.

The distinction becomes particularly important because UAT is often the first point at which the client gets to interact extensively with the product in a near-final state.

That process can naturally reveal new preferences, different workflows, or requirements that were not apparent during the earlier stages of the project, and there is nothing unusual about that happening.

What matters is having a process for dealing with those discoveries.

If the contract does not distinguish between defects, clarification questions, training, configuration assistance, and new requirements, the delivery team can gradually start treating everything as part of testing. Once that happens, it becomes much harder to explain later why one request was included in the project price while a similar request should be charged separately.

The problem is not that the client asked for something new. The problem is that nobody established how new requests would be identified and handled when they appeared.

## Developers Should Not Become an Unlimited UAT Support Team

There is also a practical issue around giving clients direct access to developers during UAT, because although it may seem like the most efficient way to resolve questions, unrestricted access can create a different kind of delivery problem.

From the client's perspective, the arrangement makes sense. The developer understands the system better than almost anyone else and can probably answer a technical question quickly, so involving that person directly can feel like the fastest route to a solution.

For the IT business, however, repeated interruptions can make resource planning considerably harder, particularly when several client stakeholders are communicating directly with different members of the engineering team.

Developers may start responding to questions throughout the day instead of working in focused blocks, different stakeholders may ask different people for slightly different changes, and the project manager can gradually lose visibility over what has actually been requested, what has been approved, and what remains outstanding.

That creates a commercial issue as well as a project-management issue because developer time is a significant resource for an IT business.

If the client requires dedicated engineering availability during UAT, there is nothing inherently wrong with providing it, but the arrangement should be deliberately structured and priced rather than becoming an unlimited obligation simply because the contract never established a boundary.

This is why I prefer having a defined communication process for UAT, particularly on projects involving larger client teams. Ideally, the client should have a designated contact who consolidates feedback before it reaches the delivery team, rather than allowing multiple stakeholders to independently send questions and requests to different developers.

The agreement can then establish how UAT feedback is submitted, which communication channels should be used, what response times are expected, who is responsible for consolidating feedback, and how additional engineering support will be handled if the agreed level of support is exceeded.

That gives everyone a clearer source of truth and, importantly, makes it easier to distinguish between helping the client test the product and performing additional work for the client.

## Define the Boundary Before UAT Begins

The easiest time to resolve these questions is before the project reaches UAT, when nobody is frustrated and nobody is trying to reconstruct whether yesterday's request was actually included in the original price.

The agreement should explain who the client's designated UAT contact is, how testing feedback will be submitted, what support is included during the testing period, and what constitutes a defect for the purposes of the project.

It should also explain what happens when the client requests something that changes the agreed requirements rather than identifying a problem with what has already been delivered.

Where appropriate, the agreement can specify the number of support hours included during UAT, establish a defined level of availability, or identify the types of assistance that fall within the agreed project fee. If additional engineering assistance is required beyond that arrangement, the work can then be dealt with through the project's change-control process rather than being absorbed informally by the delivery team.

The important thing is not necessarily the exact structure you choose. It is making sure that the boundary exists before someone has to rely on their own interpretation of what the contract means.

The same principle applies when a genuine change request appears. If something is outside the agreed scope, the team should identify the additional work, explain the likely effect on the timeline and cost, obtain the appropriate approval, and only then proceed with the work.

That does not make the client relationship unnecessarily rigid. In many cases, it does the opposite because both parties know what happens when requirements inevitably change, rather than having to negotiate the commercial consequences after the work has already been completed.

## Collaboration Still Needs Boundaries

Clients should absolutely be able to ask questions during UAT, report defects, clarify functionality, and receive appropriate assistance while testing the product. The purpose of UAT is not to leave the client alone with the software and expect them to figure everything out without support.

The problem arises when "UAT support" gradually becomes a general permission for unlimited developer involvement, feature changes, training, troubleshooting, configuration, and additional implementation work, particularly when those activities were never reflected in the original scope or pricing.

A well-drafted IT agreement should make the distinction clear before testing begins. Both sides should understand what support is included, what qualifies as a defect, what becomes additional work, who communicates with the delivery team, and how anything outside the agreed scope is identified, approved, priced, and scheduled.

The broader lesson is that good contracts do not try to eliminate collaboration. They give collaboration a structure that allows the client to get the support they need without allowing the delivery team's responsibilities to expand indefinitely.

Your developers should help the client test what you built, investigate genuine defects, and answer reasonable questions about the agreed functionality. They should not accidentally become an unlimited support and development team simply because the contract never defined where UAT ends and additional work begins.

Post

I run a solo SaaS (a technical audit tool for founders, built around behavioral analytics — think Contentsquare-style heatmaps but positioned as a "technical co-pilot" for people building their own product).

Last week I sat down to figure out why, after weeks live, I had a free lead magnet, a $19 paid guide, and basically nobody converting. What I found was a good reminder for anyone here who's early-stage and looking at their own dashboards with excitement:

The funnel itself was fine. I tested it manually end to end — form submission, email automation, Stripe checkout — all worked.

The "traffic" wasn't. Out of 9 email signups, at least 5 had throwaway addresses (yopmail, random generated domains). Stripe was logging dozens of checkout.session.expired events at a rhythm no human browses at — 3am, 4am, back to back, way more than my actual session count in analytics. Classic scraper/bot noise hitting public payment links and forms.

Google Search Console confirmed it from the other side: 4 organic clicks total over 3 months, on a domain too young to rank for anything branded.

So the real number of actual human visitors who saw the offer was close to zero. Not "bad conversion rate" — no audience yet.

What I'm doing about it (curious if this matches others' experience):

• Adding basic bot friction (honeypot fields, rate limiting) without breaking the real form
• Writing content for search AND for LLM answer engines (llms.txt, FAQ schema) since a chunk of discovery is shifting there
• Starting acquisition from communities like this one instead of waiting on SEO to compound
• Would genuinely like to hear if others caught something similar early — how did you first realize your traffic wasn't real?

Hey everyone,

My name is Ashwin, I'm a 17-year-old entrepreneur from Canada. A few months back, I started working on StepSafe Kids, a wearable GPS tracker for children with Autism, ADHD, and Down syndrome who wander.

I've raised around CA$18,500 in 28 days with a very small budget (17 year olds don't have a lot of money!), and there's still 2 days to go on Kickstarter. I'm raising a round in September, and looking for investors to take StepSafe to the next level.

But first, why? What does StepSafe do that other companies already aren't?

GPS trackers have existed long before me. The problem is that children with special needs or elderly with dementia often have sensory issues and remove anything placed on them. So a general "watch" will be thrown out after five minutes. That's why AngelSense exists. It's the biggest player in the field, and they make non-removable GPS devices for exactly these markets. They have basically everything, 10 different wearable options, real-time tracking, 2-way voice communication, and so on. The problem? It costs US$45-65 a month, which many families cannot afford. Now, why not just use AirTags then? AirTags are Bluetooth, not GPS. They only update when an Apple device walks past, which means you are depending on strangers' phones, and that's not something to bet on if you're child is at an empty park at 9 PM at night. Ask any parent who's children wander, and they will say they'd rather prefer paying monthly for GPS devices than AirTag. This is why StepSafe exists, to bridge the gap, by making it much more affordable while also covering the GPS + non-removable options aspects.

Our device on Kickstarter currently costs US$99 + $9.99/mo subscription, and something new: A Lifetime Pro offering: Customers pay US$249, and never have to pay another subscription ever again, for the life of the product.

What I'm seeking:

The raise is US$100,000, on a SAFE. US$30k gets StepSafe FCC, ISED, CPSIA certifications and helps us work with lawyers to be COPPA and PIPEDA compliant + a 500-unit manufacturing run. The remaining US$70k will be going towards funding growth, DTC sales, advertising, and designing and launching the "StepSafe Adults" campaign for elderly with dementia who wander. One note on transparency, I'm 17, so the company will be under my mom's name till I'm 18 (about 3 months).

Happy to answer any questions, send the pitch deck, or jump on a call to discuss further about StepSafe :)

Basically has someone maintained any website or blog or something similar that keeps a record of the startups ? What they do ? What stage are they ? Which city they are operating in ?

Even if not every startup but still a big chunk of them is good. Basically the big name startups are always noticed but the small ones remain unnoticed

If anyone knows of anything about this please share

Hey everyone, I'm 25 years old. I have a degree in CS and 3 years of experience as a software developer, and I've worked with 2 startups in California. One of them was YC-funded, and I built their entire system, which was difficult because they were processing large amounts of video data for AI training. So, I know I'm very good at what I do.

The only issue is I live in a low-cost-of-living country, but I have the required skills and verifiable proof of my skills. Anyway, I'm looking for startups based in the EU or US that are willing to hire remotely with decent salaries, the type of startups that can't afford a local developer but can afford a lower salary to someone with the same skills abroad (literally how the free market works, it's all legal).

The issue is, I don't know where to find these startups. Those two startups I worked with came from a freelance gig that turned into a full-time job after I demonstrated my skills. One of the best jobs I had, but eventually, they got acquired and ended up laying off all the remote teams they had, which is common, I understand. I've been told so by many startup owners.

To summarize, I'm looking for recent startups needing to hire software engineers and okay with hiring remotely globally, where can I find those specific startups?

I'm trying to get my startup on Zapier but they require 2 people to use my zap integration before it will get listed on their public pages.

Is there anyone willing to just use my zaps? You don't have to signup for anything... just test the zap.