A founder asked me last week: “Should I hire a developer or use AI to build my product?”
\nMy answer: both. But not the way you think.
\nUsing AI tools to build your product is smart. They’re fast. They’re cheap. And for many use cases, the output is genuinely good.
\nBut here’s what I keep seeing.
\nFounders use AI to build Version 1. It works. They launch. Users sign up. Revenue starts coming in.
\nThen they need Version 2. More features. Better performance. Security improvements. Compliance requirements from a new enterprise customer.
\nAnd they hit a wall.
\nThe AI-generated code wasn’t structured for extension. Adding Feature B requires understanding how Feature A was built. But the founder didn’t build Feature A. The AI did. And the AI doesn’t remember why it made the choices it made.
\nThere’s no documentation. There’s no architectural reasoning. There’s just code that works until it doesn’t.
\nThis is where the hybrid model makes sense.
\nUse AI tools for the initial build. Move fast. Validate the idea. Get to market.
\nThen bring in a developer who can do 3 things.
\nFirst, review what the AI built. Identify the gaps in security, error handling, and architecture that AI tools consistently miss.
\nSecond, restructure the foundation. Make the codebase ready for the next 12 months of features, not just the next feature.
\nThird, own the ongoing development. Someone who understands the full system, makes architecture decisions, and ships production-ready code without needing constant direction.
\nAI tools are the best first developer you’ll ever have. But they’re not the last developer you’ll need.
\nThe founders who win are the ones who know when to switch from “AI building” to “human owning.”
\nWhat’s your approach? Are you building with AI tools, with a developer, or both?
", "image": "https://venuspaneliya.com/assets/og/post-should-i-hire-a-developer-or-use-ai.jpg", "tags": [ "Founders" ] }, { "id": "https://venuspaneliya.com/writing/five-products-five-lessons/", "url": "https://venuspaneliya.com/writing/five-products-five-lessons/", "title": "5 products I shipped in the last 12 months", "summary": "5 products I shipped in the last 12 months. Not a portfolio. Not a resume.", "content_html": "5 products I shipped in the last 12 months.
\nNot a portfolio.
Not a resume.
Each one taught me something different about building for founders.
\nProduct 1: A creator platform processing $10K+ per month in payouts for 200+ creators.
\nLesson: Payments aren't a feature. They're infrastructure.
\nWe moved payout state from Stripe's API into our own database.
\nProduct 2: An InsurTech quote engine where quotes took over 10 minutes.
\nLesson: Slow isn't a server problem. It's an architecture problem.
\nProduct 3: An AI form builder for a multi-tenant SaaS platform.
\nLesson: AI features without cost controls are a ticking time bomb.
\nProduct 4: An immigration case management platform handling hundreds of active cases.
\nLesson: The best feature is the one that eliminates the support ticket.
\nWe surfaced the information users kept calling about.
\nProduct 5: An EdTech platform built on a non-profit budget.
\nLesson: Constraints force better decisions.
\nDifferent industries.
Different budgets.
Different challenges.
The pattern was the same every time.
\nIf you're building a SaaS product and need someone who works this way, my DMs are open.
\nOr book a call.
\nWhich of these five lessons resonates most with where your product is right now?
", "image": "https://venuspaneliya.com/assets/og/post-five-products-five-lessons.jpg", "tags": [ "Founders", "Stripe Connect", "Redis", "OpenAI API", "Token and cost controls" ] }, { "id": "https://venuspaneliya.com/writing/six-questions-check-a-codebase/", "url": "https://venuspaneliya.com/writing/six-questions-check-a-codebase/", "title": "Six questions to check a codebase without reading it", "summary": "You can’t read code. That’s fine. You can still evaluate whether your codebase is healthy or a ticking time bomb. You just need to ask the right questions.", "content_html": "You can’t read code. That’s fine.
\nYou can still evaluate whether your codebase is healthy or a ticking time bomb. You just need to ask the right questions.
\nMost non-technical founders rely entirely on their developer’s word when it comes to code quality. “It’s fine” or “we’re in good shape” is what they hear. Until something breaks. Then it’s “well, we have some technical debt.”
\nI put together 6 questions you can ask without understanding a single line of code. Each one reveals something specific about the health of your product.
\nNo jargon. No technical knowledge required. Just questions that force honest answers.
\nSave this. Share it with a founder friend who’s working with a developer right now.
\nNon-technical founders: what question do you wish you’d asked your developer before signing the contract?
", "image": "https://venuspaneliya.com/assets/og/post-six-questions-check-a-codebase.jpg", "tags": [ "Founders" ] }, { "id": "https://venuspaneliya.com/writing/edtech-on-a-non-profit-budget/", "url": "https://venuspaneliya.com/writing/edtech-on-a-non-profit-budget/", "title": "An EdTech platform on a non-profit budget", "summary": "A non-profit founder needed an EdTech platform built. Budget was tight.", "content_html": "A non-profit founder needed an EdTech platform built.
\nBudget was tight.
\nHere's how we made it work.
\nThe founder had a clear vision.
\nAn online learning platform for kids with interactive math exercises, progress tracking for teachers and parents, and community features.
\nThe budget was a fraction of what most agencies would quote.
\nMost developers would have said, "Cut features."
\nI said, "Let's prioritize differently."
\nWe started by identifying the three features that mattered for launch.
\nEverything else went onto a post-launch list.
\nGood ideas.
\nNot launch-critical.
\nThen we made architecture decisions that reduced cost without compromising quality.
\nThe platform launched on time.
\nInfrastructure costs stayed under $50 per month for the first 500 users.
\nThe foundation was solid enough that adding features later didn't require rebuilding.
\nHere's the lesson.
\nTight budgets force better architecture decisions.
\nWhen you can't afford to build everything, you're forced to build the right things.
\nAnd when infrastructure costs matter, you choose architectures that scale efficiently instead of architectures that are simply easy to set up.
\nConstraints aren't limitations.
\nThey're design inputs.
\nHave you ever built something on a tight budget that turned out better because of the constraint?
", "image": "https://venuspaneliya.com/assets/og/post-edtech-on-a-non-profit-budget.jpg", "tags": [ "Cloud", "Authentication and access control" ] }, { "id": "https://venuspaneliya.com/writing/most-expensive-hire-second-developer/", "url": "https://venuspaneliya.com/writing/most-expensive-hire-second-developer/", "title": "The most expensive hire is the second developer", "summary": "The most expensive hire a startup founder makes isn't the first developer. It's the second one. The one hired to fix what the first one built. I've seen this pattern repeat so many times it's almost predictable.", "content_html": "The most expensive hire a startup founder makes isn't the first developer.
\nIt's the second one.
The one hired to fix what the first one built.
I've seen this pattern repeat so many times it's almost predictable.
Here's how it goes.
\nStage 1
\nThe founder hires a developer. Usually the cheapest option. Budget is tight. Timeline is aggressive.
\nThe developer builds a working product. Screens load. Features work. The founder is happy.
\nStage 2
\nThe product gets users. Real users behave differently than demo users.
\nBugs start appearing. The developer patches them. Then more appear. Each patch introduces a new problem because the original architecture wasn't built for real-world complexity.
\nStage 3
\nThe founder wants to add features. The developer says it'll take 3 months.
\nThe founder asks why.
\nThe answer?
\nAdding Feature B requires rebuilding Feature A first. And Feature A is tangled with Features C and D.
\nStage 4
\nThe founder hires Developer 2.
\nThe total cost?
\nFor a product that could have been been built correctly the first time for $15K-$20K in 8 weeks.
\nThe prevention is simple.
\nDon't optimize for the cheapest first developer.
\nOptimize for never needing a second one.
\nAsk your first developer:
\n"If I hire someone else to maintain this code in 12 months, how hard will it be for them to understand?"
\nIf they can't answer clearly, that's your answer.
\nFounders: have you ever had to hire someone to redo what the previous developer built?
\nWhat triggered it?
", "image": "https://venuspaneliya.com/assets/og/post-most-expensive-hire-second-developer.jpg", "tags": [ "Founders" ] }, { "id": "https://venuspaneliya.com/writing/not-multi-tenancy-a-filter/", "url": "https://venuspaneliya.com/writing/not-multi-tenancy-a-filter/", "title": "That’s not multi-tenancy. That’s a filter.", "summary": "I asked an AI tool to build a multi-tenant SaaS. It built a single-tenant app with a tenant ID column.", "content_html": "I asked an AI tool to build a multi-tenant SaaS.
\nIt built a single-tenant app with a tenant ID column.
\nThat’s not multi-tenancy.
\nThat’s a filter.
\nHere’s why this matters if you’re building a SaaS product.
\nMulti-tenant means multiple customers share the same infrastructure while their data remains completely isolated.
\nWhat the AI tool built was a single application where every database table had a tenant_id column.
In theory, queries filter by tenant ID so each customer only sees their own data.
\nIn practice, this creates three serious problems.
\nEvery database query needs a tenant ID filter. Forget it on one query, one endpoint, or one admin panel, and Customer A suddenly sees Customer B’s data.
\nIn healthcare, that's a HIPAA violation.
\nIn finance, that's a lawsuit.
\nOne customer running a heavy report slows down the database for everyone else.
\nOne customer uploading 10 GB of files fills the shared storage.
\nOne customer hitting the API 50,000 times per hour degrades performance for everyone.
\nWithout proper tenant isolation, tracking usage per customer means aggregating data across shared tables by tenant ID.
\nAt scale, those queries become slow and expensive.
\nAnd if the numbers are wrong, you're either undercharging or overcharging customers.
\nReal multi-tenancy requires architectural decisions.
\nAI tools don't make these decisions because they build features one at a time.
\nMulti-tenancy is a system-level concern that touches every part of the application.
\nIf you've used AI to build a SaaS, did you check whether it's actually multi-tenant or just faking it?
\nalter table invoices enable row level security;\ncreate policy tenant_isolation on invoices\n using (tenant_id = current_setting('app.tenant_id')::uuid);Everyone’s adding AI features.
\nNobody’s asking whether their users actually need them.
\nI’ve had four conversations with founders this month that followed the same pattern.
\n“We need to add AI to the product.”
\n“Why?”
\n“Our investors are asking about our AI strategy.”
\nNot "our users are asking for it." Not "we identified a workflow that AI improves." Not "we tested it and it reduced time-to-value."
\nInvestors are asking. So founders are building.
\nThis is how you end up with:
\nThe best AI features I’ve built started with a user problem, not an investor question.
\nOne founder said, "Our users spend 45 minutes filling out forms manually."
\nWe built an AI form generator. Usage was immediate. Value was obvious. Manual editing dropped 60%.
\nAnother founder said, "Our support team answers the same 20 questions repeatedly."
\nWe restructured the product to surface those answers before users needed to ask. Support queries dropped 40%.
\nNo chatbot. No "AI-powered" label. Just better architecture.
\nThe pattern is simple.
\n"AI" on your pitch deck means nothing if your users don’t experience the value.
\nHave you added AI features because users asked, or because investors expected it?
", "image": "https://venuspaneliya.com/assets/og/post-adding-ai-features-few-users-asked.jpg", "tags": [ "AI engineering", "OpenAI API" ] }, { "id": "https://venuspaneliya.com/writing/ai-built-saas-enterprise-procurement/", "url": "https://venuspaneliya.com/writing/ai-built-saas-enterprise-procurement/", "title": "Your AI-built SaaS won’t pass enterprise procurement", "summary": "Your AI-built SaaS won’t pass enterprise procurement. Here’s what they’ll ask that you haven’t thought about.", "content_html": "Your AI-built SaaS won’t pass enterprise procurement.
\nHere’s what they’ll ask that you haven’t thought about.
\nYou built a working product. Users are signing up. Revenue is growing. Then a mid-size company wants to buy 50 seats.
\nTheir procurement team sends you a vendor security questionnaire.
\n47 questions.
\nYou freeze.
\nHere’s a preview of what’s coming.
\nYou don’t have one. User data stays in the database forever. When someone asks to delete their account, you run a manual SQL query and hope you got everything. There’s no automated process. No audit trail of what was deleted.
\nIn transit, probably yes. Most modern frameworks default to HTTPS. At rest? Almost certainly not. AI-generated code doesn’t add database-level encryption because it’s infrastructure, not a feature.
\nYou don’t have one. You Google it and discover it costs $30K to $50K and takes six months. The enterprise deal suddenly has a six-month prerequisite you didn’t know about.
\nThere’s no mechanism to export all data associated with a specific user. There’s no mechanism to delete it comprehensively across all tables and backups. There’s no logging of who accessed what data and when.
\nThere isn’t one. Because no one thought about what happens when something goes wrong. Only what happens when everything goes right.
\nHere’s the reality.
\nEnterprise customers and government buyers don’t evaluate your features. They evaluate your infrastructure, your processes, and your compliance posture.
\nAI tools build none of these.
\nIf you’re building a SaaS product and plan to sell to businesses with more than 50 employees, compliance architecture needs to be in your roadmap from month one, not month twelve.
\nNon-technical founders: does your developer talk to you about security, or do you just assume it’s handled?
", "image": "https://venuspaneliya.com/assets/og/post-ai-built-saas-enterprise-procurement.jpg", "tags": [ "Security", "Authentication and access control" ] }, { "id": "https://venuspaneliya.com/writing/what-a-5k-mvp-costs/", "url": "https://venuspaneliya.com/writing/what-a-5k-mvp-costs/", "title": "What a $5K MVP actually costs", "summary": "A founder told me his MVP cost $5,000. Six months later, he’d spent another $35,000 rebuilding it because it couldn’t handle real users.", "content_html": "A founder told me his MVP cost $5,000.
\nSix months later, he’d spent another $35,000 rebuilding it because it couldn’t handle real users.
\nTotal cost: $40,000 and 9 months. For a product he could have built right the first time for $15,000 in 8 weeks.
\nThis pattern is so common it’s almost predictable. The budget you set for your MVP determines what you get. And most founders don’t know what each price range actually buys.
\nHere’s a breakdown with real numbers. Save this before your next developer conversation.
\nWhere does your current product sit on this scale? And where do you need it to be?
", "image": "https://venuspaneliya.com/assets/og/post-what-a-5k-mvp-costs.jpg", "tags": [ "Founders" ] }, { "id": "https://venuspaneliya.com/writing/fix-the-foundation-before-ai/", "url": "https://venuspaneliya.com/writing/fix-the-foundation-before-ai/", "title": "Fix the foundation before you add AI", "summary": "A founder asked me to add AI features to her EdTech platform. I said not yet.", "content_html": "A founder asked me to add AI features to her EdTech platform.
\nI said not yet.
\nShe had a working product. Users were growing. Revenue was coming in. She wanted to add an AI-powered recommendation engine to personalize learning paths for students.
\nThe feature made sense. The timing didn’t.
\nHere’s why.
\nThe platform’s database schema was designed for the original 3 features. Adding an AI recommendation engine meant the system needed to track user behavior across sessions, store interaction patterns, and serve personalized results in real time.
\nThe existing architecture couldn’t handle any of that. Not because it was bad. It was built for what the product needed at launch. But it wasn’t built for what the product needed next.
\nIf we’d bolted AI features onto the existing foundation, two things would have happened.
\nSo we spent 6 weeks restructuring the data layer first. Normalized the schema. Added proper indexing. Built a caching layer for frequently accessed data. Set up event tracking for user behavior.
\nThen we added the AI features.
\nThey shipped in 2 weeks. Not 2 months. Because the foundation was ready.
\nThe recommendation engine worked on day one. No performance issues. No data inconsistencies. No emergency patches.
\nHere’s the lesson.
\nWhen a founder says, “I want AI features,” and a developer says, “Let’s fix the foundation first,” that developer is saving you time, not wasting it.
\nThe fastest path to AI features is rarely “add AI features.”
\nIt’s usually “make the system ready for AI features, then add them.”
\nHave you ever been told “not yet” by a developer?
\nIn hindsight, were they right?
", "image": "https://venuspaneliya.com/assets/og/post-fix-the-foundation-before-ai.jpg", "tags": [ "AI engineering", "PostgreSQL" ] }, { "id": "https://venuspaneliya.com/writing/one-developer-vs-a-40k-agency/", "url": "https://venuspaneliya.com/writing/one-developer-vs-a-40k-agency/", "title": "One senior developer or a $40,000-a-month agency", "summary": "I talked to a founder who was paying $40,000 a month to an agency. He still couldn’t get a feature shipped in under 6 weeks.", "content_html": "I talked to a founder who was paying $40,000 a month to an agency.
\nHe still couldn’t get a feature shipped in under 6 weeks.
\nNot because the agency was lazy. Not because the developers were bad. The structure itself was the problem.
\nHere’s how it worked.
\nThe founder had calls with an account manager.
The account manager translated requirements to a project manager.
The project manager assigned tickets to developers.
The developers wrote code based on tickets that had already lost half the context.
When the founder had a question about implementation, it took 3 days to get an answer.
\nThe question went from founder → account manager → project manager → developer.
\nThen the answer came back the same way.
\nFour people were involved in every decision. None of them understood both the business and the code.
\nThe agency wasn’t scamming him.
\nThis is just how agency models work at scale.
\nThey optimize for utilization, not speed. Every developer is split across 2-3 projects. Context switching is constant. Deep focus on one product is rare.
\nThen there’s the pricing math.
\n$40,000 per month sounds like you’re getting a team.
\nIn reality, you’re getting fractions of people.
\nThe total time dedicated to your product might be just 60-80 hours per month.
\nFor $40K.
\nThe alternative isn’t hiring a cheaper agency.
\nIt’s working with one senior developer embedded in your team.
\nOne person who understands the business, writes the code, and communicates directly with you.
\nNo translation layers. No context loss. No 3-day turnaround on a simple question.
\nThat model exists. It costs a fraction of what agencies charge. And it ships faster because decisions happen in minutes, not weeks.
\nHave you worked with an agency for development?
\nWhat surprised you most about the experience?
", "image": "https://venuspaneliya.com/assets/og/post-one-developer-vs-a-40k-agency.jpg", "tags": [ "Founders" ] }, { "id": "https://venuspaneliya.com/writing/three-architecture-decisions-ai-wont-make/", "url": "https://venuspaneliya.com/writing/three-architecture-decisions-ai-wont-make/", "title": "3 architecture decisions AI tools will never make for you", "summary": "There are 3 architecture decisions that AI tools will never make for you. They’ll generate code. They’ll build features. They’ll even structure your database schema in a way that looks reasonable.", "content_html": "There are 3 architecture decisions that AI tools will never make for you.
\nThey’ll generate code. They’ll build features. They’ll even structure your database schema in a way that looks reasonable.
\nBut they won’t make system-level decisions that require understanding your business, your users, and your scale requirements.
\nWhen a customer pays you through Stripe, the transaction data lives in Stripe’s system. Most AI-generated code treats Stripe as the source of truth and queries Stripe’s API every time you need payout status.
\nThe problem: Stripe’s API has latency. It has rate limits. And if Stripe goes down for 20 minutes, your entire payment dashboard goes blank.
\nThe better approach: store payment state in your own database. Use Stripe as the processor, not the record keeper. Sync events through webhooks. Now your system works even when Stripe hiccups.
\nIf you’re building AI features, every API call to OpenAI costs money. Without controls, one customer running 10,000 prompts burns through your budget while other customers get slow responses.
\nAI tools don’t add per-tenant rate limiting because they don’t think at the system level. They build features for one user at a time.
\nYou need architecture that thinks about all your users simultaneously.
\nYour product calls OpenAI. OpenAI has an outage. What does your user see?
\nMost AI-generated code shows a crash or a loading spinner that never resolves.
\nProduction-ready code shows a graceful fallback. Maybe a cached response. Maybe a message that says “this feature is temporarily unavailable.”
\nSomething that doesn’t destroy the user’s trust.
\nThese decisions require judgment.
\nAI tools generate code.
Developers make decisions.
If you’re building with AI tools, which of these 3 have you thought about?
", "image": "https://venuspaneliya.com/assets/og/post-three-architecture-decisions-ai-wont-make.jpg", "tags": [ "SaaS", "Stripe Connect", "OpenAI API", "Token and cost controls" ] }, { "id": "https://venuspaneliya.com/writing/freelance-market-two-tiers/", "url": "https://venuspaneliya.com/writing/freelance-market-two-tiers/", "title": "The freelance developer market is splitting into two tiers", "summary": "The freelance developer market is splitting into two tiers. - Tier 1: $10 to $20 per hour.", "content_html": "The freelance developer market is splitting into two tiers.
\nDevelopers who follow instructions. You write the spec, they write the code. If the spec is wrong, the code is wrong. If you miss an edge case in the brief, it doesn’t exist in the product. These developers need detailed management and frequent review.
\nDevelopers who make decisions. You describe the problem, they figure out the solution.
They catch edge cases you missed. They push back when a feature doesn’t make sense. They think about your business model, your users, and your scale requirements.
The middle is disappearing.
\nThe $25 to $35 range used to be where most freelancers lived. Competent. Reliable enough. Needed some management but not constant oversight.
\nAI tools are eating this tier.
\nA founder with Cursor can now produce what a $30/hour developer would have built.
The code quality is similar. The speed is faster. The cost is a $20/month subscription.
So what’s left?
\nFor founders, this changes the hiring calculus.
\nThe question isn’t “how much does a developer cost per hour?”
\nThe question is “how much does it cost me in total, including my time managing them, fixing their mistakes, and rebuilding what doesn’t scale?”
\nA $50/hour developer who needs zero management and ships production-ready code often costs less than a $15/hour developer who needs daily oversight and produces code that needs rebuilding in 6 months.
\nFounders: would you rather pay $20/hr and manage closely, or $50/hr and get autonomous delivery?
\nWhy?
", "image": "https://venuspaneliya.com/assets/og/post-freelance-market-two-tiers.jpg", "tags": [ "Founders", "Cursor" ] }, { "id": "https://venuspaneliya.com/writing/the-recommendation-i-didnt-ask-for/", "url": "https://venuspaneliya.com/writing/the-recommendation-i-didnt-ask-for/", "title": "The recommendation I didn’t ask for", "summary": "A few months into a contract, the client who brought me in wrote a recommendation on LinkedIn. Unsolicited. I didn’t ask for it.", "content_html": "A few months into a contract, the client who brought me in wrote a recommendation on LinkedIn.
\nUnsolicited. I didn’t ask for it.
\nThat recommendation said three things that stuck with me.
\nThis mattered because the founder had been burned before. Previous developers needed constant direction. Every feature required a detailed brief, a review cycle, and multiple rounds of feedback before anything shipped. The founder was spending more time managing the developer than running the business.
\nThis mattered because most freelance developers operate through a layer of project management. The founder talks to a PM. The PM talks to the developer. Context gets lost in translation.
\nI joined the product team directly. When a question came up, I asked the person who had the answer.
\nNo intermediary. No game of telephone.
\nThis mattered because the biggest complaint founders have about developers isn’t technical skill. It’s silence.
\nYou send a message on Monday and hear nothing until Thursday. You ask for a status update and get a vague “working on it.”
\nThis client got daily updates. Short. Specific. No fluff.
\nHere’s what I learned from this.
\nFounders don’t leave recommendations because the code was good. They leave recommendations because the experience was good.
\nBecause they didn’t have to think about the technical side. Because they could focus on their business knowing the product was being handled.
\nTechnical skill is the minimum requirement.
\nThe thing that actually earns trust is ownership.
\nIf you’re looking for a developer who works this way, my DMs are open.
\nOr book a call.
", "image": "https://venuspaneliya.com/assets/og/post-the-recommendation-i-didnt-ask-for.jpg", "tags": [ "Founders" ] }, { "id": "https://venuspaneliya.com/writing/does-your-developer-understand-your-business/", "url": "https://venuspaneliya.com/writing/does-your-developer-understand-your-business/", "title": "How do you know if your developer understands your business?", "summary": "How do you know if your developer actually understands your business? Not your tech stack. Your business.", "content_html": "How do you know if your developer actually understands your business?
\nNot your tech stack.
Your business.
I’ve worked with founders who hired developers based entirely on technical skills.
\nThe developer knew React. The developer knew AWS. The developer had 5 years of experience.
\nSix months later, the product was technically solid and completely wrong for the market.
\nThe developer built exactly what was asked for.
\nBut never questioned whether what was asked for was the right thing to build.
\nHere are 3 signs a developer actually gets your business.
\nA developer who understands business wants to know how you make money before they start building.
\nBecause the revenue model shapes every technical decision.
\nSubscription billing requires different architecture than one-time payments.
\nMarketplace commissions require different infrastructure than direct sales.
\nA developer who just says yes to everything is not a good sign.
\nThe ones who add value are the ones who say “we could build that, but your users probably need this instead” and explain why.
\n“What happens if two users edit the same record?”
“What if a payment fails halfway through checkout?”
“What if your API provider goes down?”
If your developer raises these questions before you do, they’re thinking about your product.
\nNot just your tickets.
\nHere’s the flip side.
\nThree red flags:
\nWhat’s the number one thing you look for when hiring a developer?
\nCurious what founders prioritize.
", "image": "https://venuspaneliya.com/assets/og/post-does-your-developer-understand-your-business.jpg", "tags": [ "Founders" ] }, { "id": "https://venuspaneliya.com/writing/quote-engine-10-minutes-to-under-2/", "url": "https://venuspaneliya.com/writing/quote-engine-10-minutes-to-under-2/", "title": "How a 10-minute quote engine got under 2 minutes", "summary": "A quote engine was taking over 10 minutes to return results. Users were leaving the page before their quotes loaded. The client’s support team was getting calls: “Is your site broken?”", "content_html": "A quote engine was taking over 10 minutes to return results.
\nUsers were leaving the page before their quotes loaded. The client’s support team was getting calls: “Is your site broken?”
\nIt wasn’t broken. It was just slow.
Here’s what was happening underneath.
Every time a user requested a quote, the system called 4 different insurer APIs sequentially. One after another.
\nEach API took 1 to 3 minutes to respond depending on load. The system waited for all 4 to finish before showing anything.
\nOn a good day, that was 5 minutes. On a bad day, 12.
\nThe fix was not about writing faster code.
\nCombined result: quote delivery dropped from over 10 minutes to under 2 minutes. Sometimes under 30 seconds for cached results.
\nSupport calls about speed dropped to near zero. Completion rates went up because users actually stuck around to see their quotes.
\nHere’s what this taught me.
\nWhen a product feels slow, the instinct is to optimize code or upgrade the server. But most of the time, the problem is architectural.
\nThe system is doing things in the wrong order, or doing the same work repeatedly when it doesn’t need to.
\nBefore you add more features, fix the foundation.
\nWhat’s the slowest part of your product right now? The one where you know users are dropping off?
", "image": "https://venuspaneliya.com/assets/og/post-quote-engine-10-minutes-to-under-2.jpg", "tags": [ "Fintech", "Redis", "REST APIs" ] }, { "id": "https://venuspaneliya.com/writing/mvp-90-percent-done/", "url": "https://venuspaneliya.com/writing/mvp-90-percent-done/", "title": "Your developer says the MVP is 90% done", "summary": "Your developer says the MVP is 90% done. Here’s what that actually means in real numbers.", "content_html": "Your developer says the MVP is 90% done.
\nHere’s what that actually means in real numbers.
\nThe first 90% is the part you can see. Screens load. Buttons work. The user can sign up, click around, and experience the core feature.
\nThis is the part developers build fastest because it’s the most straightforward.
\nThe last 10% is the part you can’t see. And it typically costs 2 to 3 times more than the first 90%.
\nHere’s what lives in that last 10%.
\nThis is why projects that are “90% done” take another 3 months.
\nThe last 10% isn’t one thing. It’s fifty small things that each take real time to build correctly.
\nThe solution isn’t to accept this as inevitable. The solution is to plan for it from the start.
\nBudget for the full 100%, not the visible 90%.
\nHas a developer ever told you a project was “90% done”? How long did the last 10% take?
", "image": "https://venuspaneliya.com/assets/og/post-mvp-90-percent-done.jpg", "tags": [ "Founders", "Authentication and access control", "Monitoring and debugging", "CI/CD" ] }, { "id": "https://venuspaneliya.com/writing/reviewed-a-codebase-built-with-claude/", "url": "https://venuspaneliya.com/writing/reviewed-a-codebase-built-with-claude/", "title": "I reviewed a codebase built entirely with Claude", "summary": "I reviewed a codebase built entirely with Claude last month. The founder was proud of it. And honestly, he should be. He’s not a developer. He used AI to build a working SaaS product in 3 weeks. That’s impressive.", "content_html": "I reviewed a codebase built entirely with Claude last month.
\nThe founder was proud of it. And honestly, he should be. He’s not a developer. He used AI to build a working SaaS product in 3 weeks. That’s impressive.
\nBut he asked me to look under the hood before he launched to paying customers. Here’s what I found.
\nWhat worked well:
\nFor a non-developer using AI tools, the output quality was genuinely good.
\nWhat would have broken in production:
\nNone of these problems were the founder’s fault. He asked the AI to build features. The AI built features. It just didn’t build the infrastructure that keeps those features working when real people use them.
\nThe product went from “not ready” to “production ready” in about two weeks of focused work.
\nNot a rebuild. Just filling the gaps AI tools leave behind.
\nIf you’ve built with AI tools, did you have someone review the output before launch?
", "image": "https://venuspaneliya.com/assets/og/post-reviewed-a-codebase-built-with-claude.jpg", "tags": [ "Security", "Authentication and access control" ] }, { "id": "https://venuspaneliya.com/writing/ai-will-not-replace-judgment/", "url": "https://venuspaneliya.com/writing/ai-will-not-replace-judgment/", "title": "Will AI replace developers? Wrong question.", "summary": "Everyone’s debating whether AI will replace developers. Wrong question.", "content_html": "Everyone’s debating whether AI will replace developers.
\nWrong question.
\nAI will replace developers who only know how to write code. It won’t replace developers who know how to evaluate code, make architecture decisions, and own the outcome.
\nHere’s what I mean.
\nAI tools can generate a login system in 30 seconds. But they can’t decide whether your app needs session-based auth or token-based auth based on your specific business model.
\nThey can’t determine that your multi-tenant SaaS needs tenant-isolated rate limiting to prevent one customer from crashing everyone else’s experience. They can’t look at your payment flow and say “this will silently fail for 5% of transactions.”
\nThose are judgment calls. They require understanding the business, the users, and the failure modes that only show up in production.
\nThe developers who survive the next 5 years aren’t the ones who type fastest. They’re the ones who can look at AI-generated code and ask:
\nFor founders, this changes what “hiring a developer” means.
\nYou’re not hiring someone to write code anymore. You’re hiring someone to make decisions about your product’s architecture, security, and reliability and to review what AI tools produce.
\nThe skill isn’t coding.
\nThe skill is judgment.
\nDo you think AI tools will make hiring developers easier or harder? Genuine question.
", "image": "https://venuspaneliya.com/assets/og/post-ai-will-not-replace-judgment.jpg", "tags": [ "AI engineering" ] }, { "id": "https://venuspaneliya.com/writing/security-questionnaire-ai-built-saas/", "url": "https://venuspaneliya.com/writing/security-questionnaire-ai-built-saas/", "title": "Five questions an enterprise security review will ask", "summary": "You built a working SaaS product with AI tools. Login works. Dashboard loads. Users can sign up and pay.", "content_html": "You built a working SaaS product with AI tools.
\nLogin works. Dashboard loads. Users can sign up and pay.
\nNow an enterprise prospect wants to buy. Their procurement team sends over a security questionnaire.
\nYou check. It isn’t.
\nThe database stores everything in plaintext because AI-generated code doesn’t add encryption unless you specifically ask for it.
\nYou check. You don’t.
\nThere’s no record of who accessed what data, when, or from where. The AI tool didn’t generate logging because it wasn’t part of the feature request.
\nYou check. There’s no mechanism.
\nA user asks to delete their account, and you’d have to manually dig through the database. No GDPR-compliant deletion flow exists.
\nYou check. You don’t.
\nA single user could hit your API 10,000 times per minute and you’d have no throttling. Your OpenAI bill would spike before you noticed.
\nThere isn’t one.
\nBecause the AI tool built features, not operational processes.
\nThis is the gap between “it works” and “it’s ready for real customers.”
\nAI tools are extraordinary for building quickly. But they build features, not infrastructure.
\nSecurity, compliance, and operational readiness are the foundation that separates a prototype from a product.
\nThe fix isn’t to stop using AI tools.
\nThe fix is to know what they skip and have someone fill those gaps before your first enterprise customer asks.
\nNon-technical founders,
\nDoes your developer talk to you about security?
\nOr do you just assume it’s handled?
", "image": "https://venuspaneliya.com/assets/og/post-security-questionnaire-ai-built-saas.jpg", "tags": [ "Security", "Authentication and access control", "Token and cost controls" ] }, { "id": "https://venuspaneliya.com/writing/five-questions-before-a-developer-contract/", "url": "https://venuspaneliya.com/writing/five-questions-before-a-developer-contract/", "title": "5 questions to ask before signing a developer contract", "summary": "I've worked with founders who signed developer contracts without asking a single technical question. Not because they were careless.", "content_html": "I've worked with founders who signed developer contracts without asking a single technical question.
\nNot because they were careless.
\nBecause they didn't know what to ask.
\nMost non-technical founders evaluate developers on:
\nThose matter.
\nBut they miss the questions that actually predict whether the project will succeed or fail.
\nHere are 5 questions I'd ask before signing any developer contract.
\nNone of them require technical knowledge.
\nAll of them reveal whether the developer thinks about your business or just your feature list.
\nSave this.
\nYou'll need it.
\nWhich of these 5 would you add to your next developer interview?
", "image": "https://venuspaneliya.com/assets/og/post-five-questions-before-a-developer-contract.jpg", "tags": [ "Founders" ] }, { "id": "https://venuspaneliya.com/writing/payouts-failing-silently/", "url": "https://venuspaneliya.com/writing/payouts-failing-silently/", "title": "Payouts that were failing silently", "summary": "A client’s marketplace was processing payments for 200+ creators. Everything looked fine in the dashboard. Stripe showed transactions going through. The founder was focused on growth.", "content_html": "A client’s marketplace was processing payments for 200+ creators.
\nEverything looked fine in the dashboard. Stripe showed transactions going through. The founder was focused on growth.
\nThen a creator reached out: “I didn’t get paid last month.”
\nWe dug in. Turns out, about 5-8% of payouts were failing silently. Stripe would attempt the transfer, it would fail due to a banking detail mismatch or an insufficient balance in the connected account, and the system would just… move on. No retry. No alert. No flag.
\nThe founder had no idea. The creators who were affected mostly didn’t reach out - they just stopped using the platform.
\nThe fix was not complicated.
\nWe built a webhook listener that verified every payout event from Stripe. If a transfer failed, the system flagged it, retried with exponential backoff, and notified the ops team if it failed twice.
\nWe also moved the source of truth for payout status from Stripe’s API to our own database. Stripe became the payment processor. Our system became the record keeper.
\nResult: zero missed payouts since. Over $10K/month flowing through the system reliably. The founder sleeps better. The creators trust the platform.
\nHere’s the lesson that matters for any founder running a marketplace or creator platform:
\nThey’re infrastructure you own. Payments aren’t a feature you “integrate.” If your system doesn’t verify every transaction independently, you’re trusting a third party with your customer relationships.
\nIf you’re running a marketplace - when was the last time you checked whether every payout actually landed?
", "image": "https://venuspaneliya.com/assets/og/post-payouts-failing-silently.jpg", "tags": [ "Payments", "Stripe Connect" ] }, { "id": "https://venuspaneliya.com/writing/what-cursor-apps-skip/", "url": "https://venuspaneliya.com/writing/what-cursor-apps-skip/", "title": "3 founders showed me what they built with Cursor", "summary": "3 founders showed me what they built with Cursor this month. All 3 had working products.", "content_html": "3 founders showed me what they built with Cursor this month.
\nAll 3 had working products.
\nLogin worked. Dashboards loaded. Features functioned.
\nAll 3 had the same 2 problems hiding underneath.
\nThe login screen worked.
\nBut none of the three apps handled:
\nThese aren’t edge cases.
\nThey’re Tuesday afternoon for any app with paying users.
\nAll three had Stripe integrated.
\nCharges went through.
\nBut none of them had logic for what happens when a charge fails.
\nOne founder told me, “Stripe handles that.”
\nIt doesn’t.
\nStripe processes the payment.
\nYour app decides what happens when it fails.
\nHere’s what’s worth knowing.
\nAI tools build the happy path beautifully.
\nThe screen where everything goes right.
\nBut production software is 70% about what happens when things go wrong.
\nThat’s where products break.
\nAnd that’s what AI-generated code consistently skips.
\nThe fix isn’t “don’t use AI tools.”
\nThe fix is:
\nHave you built anything with AI tools?
\nWhat broke first?
", "image": "https://venuspaneliya.com/assets/og/post-what-cursor-apps-skip.jpg", "tags": [ "SaaS", "Cursor", "Authentication and access control", "Stripe Connect" ] }, { "id": "https://venuspaneliya.com/writing/whats-running-in-production/", "url": "https://venuspaneliya.com/writing/whats-running-in-production/", "title": "What’s running in production right now", "summary": "One month into posting consistently on LinkedIn, here’s what production looks like across my active client work right now. This isn’t a highlight reel.", "content_html": "One month into posting consistently on LinkedIn, here’s what production looks like across my active client work right now.
\nThis isn’t a highlight reel.
\nIt’s a status update on systems I built that are running in production as you read this.
\nAll of these systems are live.
\nAll of them handle real users, real money, or both.
\nAll of them were built by one developer, me, working directly with the founder or CTO, embedded with their team, accumulating context over time.
\nI work with a small number of clients on a retainer basis.
\nI take on new engagements only when I have genuine bandwidth because the quality of the work depends on the context I build with each client, and that context requires sustained attention, not split focus.
\nIf you’re building a SaaS product and need a developer who can own the full technical stack from architecture and AI integration to payments and deployment, I’d welcome a conversation.
\nDM me on LinkedIn or book an intro call.
", "image": "https://venuspaneliya.com/assets/og/post-whats-running-in-production.jpg", "tags": [ "SaaS", "Stripe Connect", "OpenAI API", "AWS Lambda", "SQS" ] }, { "id": "https://venuspaneliya.com/writing/three-developers-slower-than-one/", "url": "https://venuspaneliya.com/writing/three-developers-slower-than-one/", "title": "Why 3 developers can ship slower than 1", "summary": "A startup with 3 developers should move faster than a startup with 1 developer. In theory.", "content_html": "A startup with 3 developers should move faster than a startup with 1 developer.
\nIn theory.
\nIn practice, I’ve watched 3-developer teams ship slower than solo developers on the same scope of work.
\nNot because the individual developers were bad.
Because the coordination cost was eating their output alive.
Here’s the math nobody shows you.
\n1 developer
\nOne person holds the full context.
Decisions happen in real time.
There’s no meeting to align on the API contract because the same person is building both sides of it.
\n2 developers
\nDeveloper A and Developer B need to stay synchronized.
\nThat’s manageable.
A quick daily sync, a shared document, a Slack channel.
Maybe 30 minutes of overhead per day.
3 developers
\nA-to-B.
\nA-to-C.
\nB-to-C.
\nNow you need:
\nThat’s 1-2 hours of coordination per day across the team.
\n6 developers
\nThe kind of team an agency puts together.
\nYou need:
\nThat project manager becomes the highest-value person on the team.
\nNot because they contribute code,
but because without them, nothing connects.
The overhead compounds.
Every new developer adds coordination cost that is invisible in the budget but visible in the timeline.
\nA project scoped at 8 weeks with 1 developer doesn’t become a 4-week project with 2 developers.
\nIt becomes a 6-week project with 2 developers,
because 2 weeks of total effort went to coordination.
For early-stage startups,
Pre-product-market-fit.
Burning runway.
Building version one of a product that might pivot.
\nThis math matters.
I’m not arguing that teams are bad.
I’m arguing that teams should be sized to the problem,
not to the budget or the instinct that "more people means faster."
If your entire product can be understood by one person,
it can be built by one person.
Faster, cheaper, and with zero coordination loss.
\nThe right time to grow the team is when the product complexity genuinely exceeds what one person can hold in their head.
\nNot before.
", "image": "https://venuspaneliya.com/assets/og/post-three-developers-slower-than-one.jpg", "tags": [ "Founders" ] }, { "id": "https://venuspaneliya.com/writing/walk-me-through-your-approach/", "url": "https://venuspaneliya.com/writing/walk-me-through-your-approach/", "title": "The one question to ask before hiring a developer", "summary": "There’s a question I think every founder should ask before hiring a developer. Not about the tech stack. Not about the rate. Not about availability. “Walk me through how you’d approach building this.”", "content_html": "There’s a question I think every founder should ask before hiring a developer. Not about the tech stack. Not about the rate. Not about availability.
\n“Walk me through how you’d approach building this.”
\nNot “what would you build it with.” How would you approach it.
\nBoth developers might build the same product. But the second one will make different decisions along the way.
Decisions about architecture, data modeling, payment flows, and feature scoping that account for where the product is going, not just where it is today.
This is the difference between code that works and code that lasts.
\nI’ve taken over codebases built by developers who never asked about the business model. You can tell within an hour:
\nNone of these were bugs when the code was written. They became bugs when the business grew beyond the developer’s assumptions. And the developer’s assumptions were narrow because they never asked the questions that would have expanded them.
\nWhen you’re evaluating a developer, whether it’s me or anyone else, look closely at their starting point.
\nIf they ask about frameworks first, they’re thinking about the next sprint. If they ask about your business first, they’re thinking about the next year.
\nHire accordingly.
", "image": "https://venuspaneliya.com/assets/og/post-walk-me-through-your-approach.jpg", "tags": [ "Founders" ] }, { "id": "https://venuspaneliya.com/writing/support-problem-was-architecture/", "url": "https://venuspaneliya.com/writing/support-problem-was-architecture/", "title": "The support problem that was really an architecture problem", "summary": "A client came to me with a problem that looked like a customer service problem but wasn’t. He was running an immigration case management platform.", "content_html": "A client came to me with a problem that looked like a customer service problem but wasn’t.
\nHe was running an immigration case management platform.
\nApplicants, attorneys, case managers, support staff.
\nFour different user types, all interacting with the same cases, all needing different views of the same information.
\nThe support team was drowning.
\nNot because they were bad at their jobs.
\nBecause the system forced every question through them.
\nThey had a dashboard, but it hadn’t been updated since the last developer left.
\nEvery question, no matter how simple, ended up in the support inbox.
\nThe team was spending 70% of their day answering questions that the system should have answered automatically.
\nThe founder tried hiring more support staff.
\nThat helped for a month.
\nThen volume grew and they were underwater again.
\nAdding people to a broken process just gives you more people working on a broken process.
\nThe fix wasn’t more staff.
\nIt was architecture.
\nI built a multi-role portal.
\nThe information was already in the database.
\nIt just wasn’t being surfaced to the people who needed it.
\nAfter launch, inbound support queries dropped by approximately 40%.
\nThe founder didn’t hire those extra support staff.
\nThe existing team went from spending most of their day on repetitive status questions to handling only the cases that genuinely needed human judgment.
\nThis is what I mean when I say I try to understand the business flow before writing code.
\nThe technical build wasn’t complicated.
\nStandard tools.
\nThe insight that made it work wasn’t technical.
\nIt was recognizing that the support problem was actually an information architecture problem.
\nA different developer might have built a better ticketing system.
\nI built a system that made most tickets unnecessary.
", "image": "https://venuspaneliya.com/assets/og/post-support-problem-was-architecture.jpg", "tags": [ "SaaS", "React", "Authentication and access control" ] }, { "id": "https://venuspaneliya.com/writing/add-ai-in-one-sentence/", "url": "https://venuspaneliya.com/writing/add-ai-in-one-sentence/", "title": "Can you say what AI does for your users in one sentence?", "summary": "Every second startup I talk to wants to “add AI” to their product. Only about 1 in 5 can tell me what AI would actually do for their users.", "content_html": "Every second startup I talk to wants to “add AI” to their product.
\nOnly about 1 in 5 can tell me what AI would actually do for their users.
\nNot for their pitch deck.
Not for their investor update.
For their users.
If you can’t describe the user problem AI solves in one sentence, you’re not ready to build it yet. That’s not a criticism.
That’s the most expensive mistake I see founders make right now.
The best AI features I’ve built started with a founder saying something like: "my users spend 20 minutes building a form manually every single time." That’s specific. That’s measurable. That’s worth automating.
\nThe worst requests start with: "our competitors launched an AI feature."
\nThat’s not a product decision. That’s a panic decision.
\nAnd panic decisions are what The Rebuild Tax feeds on.
", "image": "https://venuspaneliya.com/assets/og/post-add-ai-in-one-sentence.jpg", "tags": [ "AI engineering" ] }, { "id": "https://venuspaneliya.com/writing/a-client-who-keeps-coming-back/", "url": "https://venuspaneliya.com/writing/a-client-who-keeps-coming-back/", "title": "A client who keeps coming back", "summary": "One of the clients I’ve worked with longest sent me a recommendation a few months ago. We’ve been working together across multiple projects, AI-powered SaaS builds, serverless infrastructure on AWS, and production systems handling real...", "content_html": "One of the clients I’ve worked with longest sent me a recommendation a few months ago. We’ve been working together across multiple projects, AI-powered SaaS builds, serverless infrastructure on AWS, and production systems handling real users and real money.
\nHere’s what he wrote:
\n“I’ve been working with Venus across multiple production projects involving AI-powered SaaS products and serverless infrastructure on AWS, and we continue to work together.
\nVenus has handled full-stack architecture using React, TypeScript, Supabase, and the OpenAI API shipping to production. Communication has always been clear and proactive throughout. The kind of engineer you can trust to own a feature end-to-end. I’d highly recommend Venus for any AI SaaS or full-stack build.”
\nTwo things stand out to me about that testimonial:
\nFirst: “We continue to work together.”
This isn’t a review from someone I worked with once. It’s from an ongoing relationship spanning multiple projects and multiple production deployments.
He keeps coming back because the working relationship compounds, I understand his architecture, his business logic, and his priorities. Every new project starts faster because I already carry the context from the last one.
Second: “The kind of engineer you can trust to own a feature end-to-end.”
Ownership isn’t just building what you’re told. It’s understanding why you’re building it, flagging problems before they become emergencies, and making decisions that account for where the product is going, not just where it is today.
That’s the working relationship I build with every long-term client.
\nNot just a developer who shows up, writes code, and submits a timesheet. A developer who thinks about your product the way you think about your product.
\nI work on a retainer basis with a small number of clients.
\n