Backlog

Next up

In Progress

Done

Main Roadmap

In Review

Register as Sole Proprietor - udyamregistration.gov.in (Then Sign up for Stripe Connect)

Harshil S

Users complete micro-tasks in exchange for extra credits or features inside the app — watch a 15-second clip, tag an AI response as helpful or not, rate a product. Developer earns per completed action. This is the "offerwall" model from mobile gaming but rebuilt for AI apps. It's fundamentally different from surveys (passive questions) — this is active participation that generates labeled data, marketing intel, and brand engagement simultaneously.

Rewarded Actions (Attention Exchange)

Let developers add a usage limit to their free tier ("You've used 10/10 free generations") and let users unlock more via a Zerocost-managed paywall — either by watching an ad, completing a survey, or a micropayment. Developer gets the revenue without building billing infrastructure. Huge for solo builders.

Freemium Gate SDK

Every developer you refer earns you 10% of their first $1K in earnings. Turns SDK into a viral growth engine where successful developers recruit other developers.

Developer Affiliate Program (10% Referral Commission)

We do not always need consent for ads. Under GDPR, consent is generally not required for non-personalized contextual ads that do not rely on personal data, profiling, or behavioral tracking. Since Zerocost focuses on privacy-first contextual advertising, many ad placements may operate under legitimate interest or outside consent requirements depending on implementation and jurisdiction. However, developers remain responsible for ensuring their own compliance based on how they use the product.To make this practical, Zerocost should support two consent models. First, developers can use the built-in Zerocost consent popup (triggered from the shield/privacy button), where users can manage permissions for products like data collection or recordings. Second, developers should be able to run their own custom consent flow, such as collecting consent during registration, onboarding, account creation, or inside their own privacy settings page.This should be controlled directly in the Zerocost dashboard with a clear Enable / Disable Consent Popup setting. If enabled, Zerocost handles the consent UI and stores consent states through the SDK. If disabled, the developer confirms they are managing consent independently and acknowledges that legal compliance obligations (GDPR, ePrivacy, CCPA, and other applicable laws) become their responsibility.Additionally, the dashboard should include API hooks or SDK methods so developers using custom consent flows can pass verified consent states into Zerocost. This gives startups flexibility while ensuring Zerocost can still respect user preferences technically. The result is a system that works for both privacy-conscious builders who want turnkey compliance tools and advanced teams who prefer to manage consent inside their own product experience. (We need a solid plan for all of this so before building make a plan). NOTE: We must also update our TOS, Privacy Policy, Docs. Legally, it can be permissible for Zerocost to let developers handle consent instead of Zerocost always handling it, if roles, responsibilities, and data flows are structured correctly. This is common in SaaS/SDK ecosystems. For example, many analytics, ad tech, CRM, and customer-support SDKs rely on the website/app operator to obtain consent.<h2>Why this can be valid</h2>Under laws like GDPR and the ePrivacy Directive:<ul><li>The app developer / website operator is usually the primary party interacting with the end user.</li><li>They often act as the controller (or joint controller in some cases) for user data collected through third-party SDKs.</li><li>A vendor like Zerocost can act as a processor for some services, or an independent/joint controller for others depending on product design.</li></ul>That means the app can collect consent in its own signup flow, cookie banner, onboarding, or privacy center, then pass the consent signal to Zerocost.<h2>But only if these conditions are met</h2><h3>1. Clear contractual allocation</h3>Your Terms, DPA, and dashboard settings should clearly state:<ul><li>If developer disables Zerocost consent UI, developer confirms they obtain valid consent where required.</li><li>Developer must provide required notices.</li><li>Developer must pass consent signals accurately.</li><li>Zerocost may suspend products if no lawful basis exists.</li></ul><h3>2. Zerocost must technically honor consent</h3>If user has not consented (where needed), Zerocost should not collect/process that data. Example:<ul><li>Ads product (contextual only): maybe no consent needed in some regions/use cases.</li><li>Product 2 datasets: likely higher risk, often consent strongly recommended.</li><li>Product 3 recordings: explicit consent strongly advisable.</li></ul><h3>3. Granular consent by product</h3>User should be able to separately agree/refuse:<ul><li>Contextual ads</li><li>Interaction data monetization</li><li>Recordings / session capture</li></ul><h3>4. Audit trail</h3>Store timestamp, version of notice, region, consent state source (“developer-managed” vs “Zerocost popup”).<h2>Important risk area</h2>You cannot simply say “developer is responsible” and ignore everything. Regulators look at actual control and benefit, not only contracts. If Zerocost determines purposes/means of processing, you may still have obligations.<h2>Practical best model for Zerocost</h2>Use a hybrid system:<h3>Default</h3>Zerocost popup enabled (easy compliance path)<h3>Advanced mode</h3>Developer disables popup and uses custom consent manager.Require them to certify:<ul><li>lawful basis obtained where required</li><li>notices updated</li><li>consent revocable</li><li>signals passed to Zerocost SDK</li></ul><h3>SDK example</h3><pre><code>zc.consent.sync({
 ads: true,
 datasets: false,
 recordings: false,
 source: "developer_cmp"
})</code></pre><h2>Strategic recommendation</h2>For trust + scale, market it as:“Bring your own consent manager, or use Zerocost’s built-in privacy controls.”That is stronger than forcing everyone into one popup.

Planned

Modify Consent Workflow (Click to Read - Very Long Spec)

Try Fastlane for Marketing (https://www.usefastlane.ai/)

<file-preview-component data-featurebase-content-filename="ZeroCost_Distribution_Plan (1).pdf" data-featurebase-content-filesize="586902" data-featurebase-content-filetype="application/pdf" data-featurebase-content-key="69b3ddcc99b7bca505e0a4c2/post/69e85c1fc5f04b9a5a83f7e0/019db3a7-6a19-7db8-8b86-2ac957af2fb4/b64u-WmVyb0Nvc3RfRGlzdHJpYnV0aW9uX1BsYW4gKDEpLnBkZg.pdf" src="https://69b3ddcc99b7bca505e0a4c2.featurebase-attachments.com/c/post/69e85c1fc5f04b9a5a83f7e0/019db3a7-6a19-7db8-8b86-2ac957af2fb4/b64u-WmVyb0Nvc3RfRGlzdHJpYnV0aW9uX1BsYW4gKDEpLnBkZg.pdf?X-Amz-Expires=3600&amp;X-Amz-Date=20260601T120000Z&amp;X-Amz-Algorithm=AWS4-HMAC-SHA256&amp;X-Amz-Credential=DO801TYC4FCVNNEKURKM%2F20260601%2Ffra1%2Fs3%2Faws4_request&amp;X-Amz-SignedHeaders=host&amp;X-Amz-Signature=af5a8a24634e75bfb10f18bdd768f8150561e6c1f3a589b6076384ba89dfaeb3"></file-preview-component>Read the above document. Also for the 100 day series (Day 1 of 100 building a free AI app) - we subtly mention how its free and how we make the free plan more accessible by subsidizing with revenue from Zerocost.AI App Ideas for the Series:<ul><li>StonerGPT (Clone of stonedgpt.app)<ul><li>We make the free plan fully powered by Zerocost revenue: ads and LLM convo data. And then like a pro plan for $9.99/mo with multimodal file upload support. For marketers and those needing creative uses</li></ul></li><li>CoverLetterGPT / ResumeGPT</li><li>(ADD MORE IDEAS)</li></ul>

Distribution & Product Plan (Click to Read Doc)

Make role-based targeting off(set to false) on default

<h1 style="text-align: start">Comprehensive Database Schema Optimization &amp; Security Plan</h1><h2 style="text-align: start">1. Problem Statement &amp; Root Cause Analysis</h2><h3 style="text-align: start">A. Metric Accuracy &amp; Role Tracking Issues</h3><ul><li>Symptom: Admin dashboard counts are mismatched (e.g., showing 25 users in one place but 26 in another; 24 startups vs 22 actual startups).</li><li>Root Cause: Role tracking is currently split between <code>profiles.role</code> and a separate <code>user_roles</code> table. TheOverviewPage.tsx counts "Total Users" from <code>profiles</code> but counts "Startups/Partners" from <code>user_roles</code>. If a newly registered user (especially via Google OAuth) is inserted into <code>profiles</code> but has a mismatched or missing entry in <code>user_roles</code>, the counts skew.</li><li>Goal: Unify role tracking to a single source of truth (<code>profiles.role</code>) and eliminate the redundant <code>user_roles</code> table entirely.</li></ul><h3 style="text-align: start">B. Security Vulnerabilities (Supabase Linter Errors)</h3><ul><li>Symptom: Database linter is throwing <code>SECURITY DEFINER</code> and <code>RLS Disabled</code> errors.</li><li>Root Cause:<ol><li><code>partner_wallet_stats</code> view joins directly with <code>auth.users</code> AND is marked <code>SECURITY DEFINER</code>, exposing sensitive authentication data globally.</li><li><code>app_unified_revenue</code> and <code>live_datasets</code> are also <code>SECURITY DEFINER</code> views which bypass RLS of the querying user.</li><li>Several tables (<code>app_ad_summaries</code>, <code>app_daily_ad_stats</code>, <code>app_dataset_summaries</code>, <code>domain_taxonomy</code>) simply lack Row Level Security (RLS) entirely.</li></ol></li><li>Goal: Convert views to use <code>SECURITY INVOKER</code> or remove them, decouple from <code>auth.users</code>, and apply strict RLS policies to all remaining tables.</li></ul><h3 style="text-align: start">C. Schema Redundancy &amp; Dead Code</h3><ul><li>Symptom: Bloated tables, confusing settings relationships, empty or unused LLM tracking tables.</li><li>Root Cause:<ul><li>Settings are scattered: <code>app_settings</code> holds general preferences, while <code>app_profiles</code> holds app-level info, and <code>enterprise_profiles</code> holds partner info. They share redundant fields (like bank details, notifications).</li><li>Ad stats are fragmented: <code>app_daily_ad_stats</code> and <code>app_ad_summaries</code> track clicks/impressions separately from the main <code>app_daily_revenue_stats</code> pipeline.</li><li>Wise (TransferWise) is no longer being used as the payout provider, but <code>wise_*</code> fields pollute multiple tables.</li><li>Outdated or empty LLM pipeline tables (<code>dpo_triplets</code>, <code>interaction_pairs</code>) from legacy features.</li></ul></li><li>Goal: Merge settings into role-specific profiles, aggregate stats accurately, and purge unused columns/tables to slim down the schema significantly.</li></ul><div data-type="horizontalRule"><hr></div><h2 style="text-align: start">2. Infrastructure &amp; Database Changes (Phase 1)</h2>We will execute these changes via a new SQL migration file (e.g., <code>20260518_schema_optimization_and_rls.sql</code>).1. Drop Wise Integrations<ul><li><code>ALTER TABLE platform_settings DROP COLUMN wise_payment_links;</code></li><li><code>ALTER TABLE payouts DROP COLUMN wise_transfer_id;</code></li><li><code>ALTER TABLE enterprise_profiles DROP COLUMN wise_recipient_id;</code></li><li><code>ALTER TABLE app_profiles DROP COLUMN wise_recipient_id;</code></li></ul>2. Eliminate Unused/Redundant Tables<ul><li><code>DROP TABLE user_roles;</code> (Migrating data to <code>profiles.role</code> first if needed)</li><li><code>DROP TABLE app_settings;</code> (Fields migrating to <code>app_profiles</code> and <code>enterprise_profiles</code>)</li><li><code>DROP TABLE dpo_triplets CASCADE;</code> (Unused LLM data)</li><li><code>DROP TABLE interaction_pairs CASCADE;</code> (Unused LLM data)</li><li><code>DROP TABLE app_ad_summaries CASCADE;</code> (Replaced by <code>app_daily_revenue_stats</code>)</li><li><code>DROP TABLE app_daily_ad_stats CASCADE;</code></li></ul>3. Consolidate Settings into Profiles<ul><li>Extend <code>app_profiles</code> to hold startup-specific notification defaults and bank details that were previously in <code>app_settings</code>.</li><li>Extend <code>enterprise_profiles</code> to hold its respective financial/contact info if missing.</li></ul>4. Refactor Security &amp; Views<ul><li>Drop the <code>app_unified_revenue</code> view. We will query unified metrics directly from <code>app_daily_revenue_stats</code> via the frontend or a simple RPC function to prevent security bypass.</li><li>Drop and recreate <code>partner_wallet_stats</code> to be <code>SECURITY INVOKER</code>. Replace the dependency on <code>auth.users</code> by joining <code>billing_transactions</code>, <code>dataset_purchases</code>, and <code>campaigns</code> explicitly against <code>profiles</code>.</li><li>Recreate <code>live_datasets</code> as <code>SECURITY INVOKER</code>.</li><li>Remove <code>admin_platform_stats</code> view entirely, or refactor it into an RPC to fetch active totals.</li></ul>5. Apply 100% RLS Coverage<ul><li><code>ALTER TABLE app_dataset_summaries ENABLE ROW LEVEL SECURITY;</code> + Policy</li><li><code>ALTER TABLE domain_taxonomy ENABLE ROW LEVEL SECURITY;</code> + Policy (Likely just a public read policy: <code>FOR SELECT USING (true)</code> )</li></ul><div data-type="horizontalRule"><hr></div><h2 style="text-align: start">3. Application &amp; Frontend Updates (Phase 2)</h2>We will make ZERO changes to the UI design/layout. All updates are scoped exclusively to the data layer, React Hooks, and Zustand Stores.<h3 style="text-align: start">A. Auth &amp; Role Handling (</h3>src/stores/auth-store.ts)<ul><li>Remove all references to the <code>user_roles</code> table.</li><li>OverhaulfetchAppUser to solely check <code>profiles.role</code> to determine if a user is a <code>startup</code>, <code>partner</code>, or <code>admin</code>.</li><li>UpdatesetUserRole to only fire an <code>UPDATE</code> on <code>profiles</code>.</li></ul><h3 style="text-align: start">B. Admin Dashboard Metrics (</h3>src/pages/admin/OverviewPage.tsx&amp;UsersPage.tsx)<ul><li>Action: Fix the metric inaccuracies (e.g., 25 vs 26 count bug).</li><li>Change: Remove queries to <code>user_roles</code>. InOverviewPage.tsx, we will fetch the total count, startup count, and partner count natively from the <code>profiles</code> table via a single <code>.select('role, id')</code> call.</li><li>Change: InUsersPage.tsx, map the user list from the <code>profiles</code> join cleanly.</li></ul><h3 style="text-align: start">C. Startup Dashboard Settings (</h3>src/stores/startup-store.ts)<ul><li>Change: Remove thefetchAppSettings andupsertAppSettings methods.</li><li>Replace their functionality insidefetchAppProfile andupsertAppProfile. Settings queries that originally looked for <code>discord_notify</code> or <code>currency</code> will now pull directly from the consolidated <code>app_profiles</code> row.</li></ul><h3 style="text-align: start">D. Revenue Graphs &amp; Ad Stats (</h3>src/lib/startup-revenue.ts)<ul><li>Action: Ensure the UI doesn't rely on dropped tables (<code>app_ad_summaries</code> or <code>app_daily_ad_stats</code>).</li><li>Change: ThefetchStartupRevenueSnapshot logic will be streamlined to pull purely from <code>app_daily_revenue_stats</code> and <code>payouts</code>, ensuring clicks, impressions, and revenue are strictly tied to our ledger-verified statistics rather than detached logs.</li></ul><h3 style="text-align: start">E. Partner Enterprise Config (</h3>src/lib/partner-enterprise.tsor related)<ul><li>Change: Remove attempts to read/write <code>wise_recipient_id</code> or query legacy <code>partner_wallet_stats</code> view with exposed auth dependencies.</li></ul><div data-type="horizontalRule"><hr></div><h2 style="text-align: start">4. Execution Strategy</h2>To ensure zero downtime or breaking changes in the browser, the execution will follow this precise order:<ol><li>Migration File Generation: Write the SQL to copy any straggling data (<code>user_roles</code> -&gt; <code>profiles.role</code>, <code>app_settings</code> -&gt; <code>app_profiles</code>), drop the tables, alter the views, and enable RLS.</li><li>Frontend Wiring: Update the TypeScript interfaces, Zustand stores (auth-store.ts,startup-store.ts), and helper utilities (startup-revenue.ts) to match the new schema structure.</li><li>Admin Panel Update: Overhaul the data-fetching queries inOverviewPage.tsx andUsersPage.tsx to restore 100% metric accuracy.</li><li>Validation: Run TypeScript type-checking to ensure no broken imports or missing keys remain.</li></ol>

REDUCE DB DATA REDUNDANCY / DB SECURITY

<a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://claude.ai/share/31f96692-014d-4628-b56f-605e1a82d1b2">https://claude.ai/share/31f96692-014d-4628-b56f-605e1a82d1b2</a> <h2>Step 1: Rotate the JWT Secret</h2><ol><li>Go to <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="http://supabase.com">supabase.com</a> and log in</li><li>Open your project</li><li>Click Project Settings (gear icon, bottom left sidebar)</li><li>Click Data API or JWT Keys in the settings menu</li><li>Find the Legacy JWT Secret tab</li><li>Click Change Legacy Secret</li><li>Click Generate a random secret</li><li>Read the confirmation dialog — it warns you everything breaks instantly</li><li>Confirm it</li></ol>✅ Anon key and service role key auto-regenerate after this.<div data-type="horizontalRule"><hr></div><h2>Step 2: Rotate the Database Password</h2><ol><li>Still in Project Settings</li><li>Click Database in the left menu</li><li>Scroll down to Database password</li><li>Click Reset database password</li><li>Save the new password in a password manager</li></ol><div data-type="horizontalRule"><hr></div><h2>Step 3: Get Your New API Keys</h2><ol><li>Go to Project Settings → Data API</li><li>Copy the new anon key and service role key</li></ol><div data-type="horizontalRule"><hr></div><h2>Step 4: Update Your App's Environment Variables</h2><ol><li>Open your <code>.env</code> file or your hosting dashboard (Vercel, Railway, etc.)</li><li>Replace the old <code>SUPABASE_ANON_KEY</code> and <code>SUPABASE_SERVICE_ROLE_KEY</code> with the new ones</li><li>Redeploy your app</li></ol><div data-type="horizontalRule"><hr></div><h2>Step 5: Rotate Edge Function Secrets</h2><ol><li>Go to Project Settings → Edge Functions → Secrets</li><li>Delete all old secrets</li><li>Re-add them with fresh values (OpenAI keys, any third party stuff, etc.)</li></ol><div data-type="horizontalRule"><hr></div><h2>Step 7: Change Dashboard Passwords + Enable MFA</h2><ol><li>Go to your Supabase account settings</li><li>Change your password</li><li>Enable MFA</li><li>Have jeet (co-owner) do the same</li></ol><div data-type="horizontalRule"><hr></div><h2>Step 8: Audit What Happened</h2><ol><li>Go to Logs Explorer in your project sidebar</li><li>Check for suspicious activity around March 21 (when the attacker was active)</li><li>Make sure no unknown edge functions exist in your project</li></ol>

Supabase Security Rotation Steps (Click to Read)

Make RLS enabled for ALL tables

Update Landing Page (Read my Notebook)

Rotate keys in .env

DB ATTACKED - Rotate all keys, secrets, passwords

Completed

Admin's view for user's balance is not accurate. For both partners and startups.

When partner tops up, whop takes 1-2 days to approve, and then the payment status never updates for user. It just stays as "pending"

Mention that Whop takes Fees during top up.

<ul><li>Geographies field should not be there. It will be global on default.</li><li>No device types field.</li><li>Fix Audience Segments (It should be just the industries theyve chosen/ have option for in their account settings)</li><li>Remove App Categories (show ads in these types of apps) - That will come under our new audience segments fix</li><li>Ensure daily/lifetime budget filters actually work</li><li>For the Bid Strategy section - ONLY CPM. </li><li>No “Max Bid ($) *” or Frequency Cap (per user/day)” fields.</li><li>Remove scheduling section. </li></ul>

Fix Campaign (THE FULL FLOW IS MESSED UP) (CLICK TO READ)

In Emails/Contact message replies from Resend, cc: harshilsav1@gmail.com

<a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://vercel.com/harshil12345000s-projects/zerocost/analytics?environment=all">https://vercel.com/harshil12345000s-projects/zerocost/analytics?environment=all</a>

Add Vercel Analytics (https://vercel.com/harshil12345000s-projects/zerocost/analytics?environment=all)

Add Usecasely to usecasely.zerocost.app (Do similar with more free tools for people to use - indirect marketing for Zerocost)

Personalized use cases made by AI. Example MVP by claude:<a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://usecasely.vercel.app/">https://usecasely.vercel.app</a>

Add Use Cases tab

Add Discord Link to Help Server - Invite - (https://discord.gg/DYdZZKRKHk)

Current statement: “Monetize your startup without charging users” — but this overpromises since Zerocost currently provides supplemental revenue, not full monetization. The dilemma is balancing honesty (it’s just extra revenue today) with strong positioning (it still feels like monetization).Both are strong, but they signal slightly different things.<ol><li>“Turn your free users into revenue” - THIS IS BEST More powerful + punchy Feels like a core transformation Broader (doesn’t lock you into one method) Better as a headline </li><li>“Monetize your free users (without paywalls)” More explicit Immediately explains how (no paywalls) Slightly more “SaaS/technical” tone Feels like a feature/value prop</li></ol>