Forem: Donald Wono

The math behind "Vibe Coding": Why 75% of startups are crushed by Giants.

Donald Wono — Tue, 24 Feb 2026 14:21:10 +0000

Right now, my feed is flooded with influencers telling developers they can "vibe code" an AI wrapper over the weekend, launch it, and retire to Bali.

The narrative is that AI has made building software so easy that anyone can become a millionaire overnight. But nobody is talking about what happens on Monday.

If your product is so simple that you can build it by chatting with an AI for 48 hours, so can 10,000 other people. And more importantly, a "Giant" (like Google, Microsoft, or OpenAI) can build it as a native feature in an afternoon.

As an indie dev building a BI tool (NeoShift BI), I prefer looking at databases over hype. I grabbed a dataset of 409 real startup post-mortems from Kaggle and dropped it into NeoShift to see what actually kills tech companies.

Here is the brutal reality check.

The Zero-Moat Problem

The "get rich quick" influencers tell you that startups fail because they run out of cash or build a bad product. The data says otherwise:

Only 18.8% failed because they ran out of budget.
Only 19.8% failed because of poor market fit.

The overwhelming majority of these startups were slaughtered by two things: Established Giants (75.3%) and Intense Market Competition (71.1%).

If you are vibe-coding a generic AI wrapper, you aren't competing on code quality. You are walking straight into a meat grinder against incumbents with 100x the capital, distribution, and brand recognition. Execution is cheap; defensibility is hard.

How to survive: Strategic Invisibility

I didn't want to just look at static charts, so I fed this live data into a new AI feature I just shipped for NeoShift BI called "Insight Blocks." I asked the AI to analyze the failure rates and generate a strategic playbook for solo developers.

Here is what the AI wrote:

"For solo developers, survival demands strategic invisibility. The path forward is not to build 'better' versions of existing tools or compete in crowded categories. Instead, target hyper-specific micro-niches—problems so narrow that Giants cannot justify the opportunity cost of pursuing them. >
A $500K annual revenue niche is irrelevant to a public company but life-changing for an individual. Build for audiences measured in thousands: tools for niche professions (court reporters, arborists, yacht brokers), or workflows specific to regional regulations. The goal is to operate below the radar of competitive threats. Dominate the overlooked corners where Giants won't follow."

See the full breakdown

If you want to interact with the data, and see the full AI-generated Executive Summary, I published the interactive dashboard here (No login required):
👉 Neoshift BI - Startup Failure Prediction Dashboard

🏆 The NeoShift BI Open Beta Challenge

To celebrate shipping our new AI Insight and Image blocks, I am extending the NeoShift Open Beta until March 31st and launching a month-long data storytelling challenge.

I have unlocked 1 Free Public Share Link for all Basic users who sign up.

Use Beta Code: BETA-1F2FF553
Link: Neoshift BI - Register

The Challenge:
Find a weird, interesting, or contrarian dataset (if you need inspiration, Kaggle is a goldmine for amazing free datasets). Drop it into NeoShift, let the AI generate an Insight report, and drop your public link in the comments below.

On Friday, March 27th, the dashboard with the highest combined score wins a Free Lifetime Enterprise Account with 100GB data storage and 5 user seats.

How to win (100 Point System):

+10 points for creating a Public Share Link.
+10 points for having 2 or more types of charts on your dashboard.
+15 points for adding an AI Insight Block to your dashboard.
+15 points for adding an Image Block to your dashboard.
+10 to +50 points based on traffic (10 pts for 10-49 unique views, scaling up to 50 pts for 500+ views).

If there is a tie, we will look at which dashboard has the most unique views.

📊 Track the Live Standings:
I am tracking the competition using—you guessed it—a NeoShift dashboard connected to our Google Analytics API. The board is wide open right now. Claim the #1 spot today:
👉 Live Competition Leaderboard

Let's see what you can build. May the best data win! 👇

I analyzed 153,000 Tech Layoffs to see if AI is actually stealing our jobs.

Donald Wono — Thu, 19 Feb 2026 10:20:43 +0000

There is a growing trend of executives blaming "AI automation" for recent tech layoffs. Analysts call it "AI-washing"—using the AI hype cycle as a scapegoat to mask internal financial issues or over-hiring.

I was tired of the think-pieces, so I wanted to look at the raw data.

I grabbed a dataset tracking 153,522 tech layoffs across 35 major companies (Jan 2025 - Feb 2026) and dropped it into my BI tool, NeoShift BI.

Here is what the data actually says.

The Reality of AI-Driven Layoffs

14.15% were explicitly tagged as being driven by AI automation.
31.77% were partially attributed to it.
54.08% had no relation to AI.

Nearly half of all workforce reductions in this dataset involved AI in some capacity. It is not just a scapegoat; it is a measurable factor.

Where the money is moving

While legacy departments are shrinking, the dataset also tracks open headcount. Hiring for roles like ML Engineers and Cloud Security Engineers is surging, with average salaries hovering near the $200k mark. The jobs aren't disappearing; they are transitioning.

Play with the data yourself

I didn't want to just post static screenshots.

I actually used this dataset to test a new feature I shipped today for NeoShift BI: Public Dashboards. You don't need to log in or create an account. You can click the link below to interact with the live charts, hover over the data points yourself:

👉 Layoffs/AI Impact

Building the Dashboard (Product Update)

If you are curious about how the visualizations were made, I recently unified the AI generation UI in NeoShift.

I literally just uploaded the raw Kaggle CSV, and the AI handled the SQL joins and charting was easily done by describing what I wanted to see. If you work with messy datasets or need to build client portals without paying per-user licensing fees, come try the Open Beta.

What dataset should I visualize next? Let me know in the comments.

I built an "Agentic" SQL Generator because LLMs are bad at syntax.

Donald Wono — Wed, 18 Feb 2026 06:40:07 +0000

I’ve been quiet for the last week. No marketing, no tweets.
I’ve been heads-down refactoring the core engine of my tool, NeoShift BI.

Building a "Text-to-SQL" tool is easy. There are 100 tutorials on how to do it.
Building one that actually works in production—handling messy APIs, SQL errors, and client-facing dashboards—is a nightmare.

Here is a breakdown of the 3 major engineering challenges I solved this week.

1. The "Self-Healing" SQL Engine (Agentic AI)

The Problem:
LLMs are great, but they hallucinate.
Sometimes they try to query a column that doesn't exist. Sometimes they mess up a JOIN syntax.
In the old version, if the generated SQL failed, the user just got a red error message: Postgres Error: Column 'revenue' does not exist.

The user would then leave. Churn. 📉

The Fix:
I implemented an Agentic Loop.
Now, when the user asks a question:

AI Generates SQL.
System Executes SQL.
IF Error: The System catches the error message (e.g., Syntax Error).
Loop: The System feeds the original SQL + the Error Message back to the AI.
AI Fixes: "Oh, I see. I used the wrong alias. Here is the corrected query."
Success.

The user never sees the error. They just see the chart. It’s a "Junior Dev" that fixes its own bugs.

2. The "Real World" API Connector

The Problem:
Most BI tools have a "Generic API Connector" that is useless.
They usually only support a basic GET request.
But if you've ever worked with real SaaS APIs (Stripe, Shopify, or internal tools), you know they require:

• Cursor-based Pagination (fetching 10,000 rows).

• Dynamic Headers (Auth tokens).

• State-based Syncing (Only fetch data that changed since last_sync).

The Fix:
I re-wrote the ingestion engine to support all of this.
You can now define:

• Path/Query Parameters

• Body Parameters (for complex POST search queries)

• Incremental Syncing via Cursor + State

Basically, if you can curl it, I can chart it.

3. Architecture for "Shared Dashboards" (Solving the Cost Problem)

The Problem:
I wanted to let users share dashboards with their clients (Client Portals).
The industry standard (Power BI) charges a "View License" per user. This is because every time a user views a dashboard, it hits the database.

If I let my users have unlimited viewers, and they all hit BigQuery at once, I’d go bankrupt on compute costs. 💸

The Fix: Smart Caching Strategy
I implemented a middleware caching layer using MongoDB.

Data Ingestion: We sync data from your source (API/SQL) into BigQuery.
View Caching: When a dashboard is loaded, we check the TTL (Time To Live).

• Pro Plan: 1 Hour TTL.

• Business Plan: 30 Minute TTL.

The Fetch: If the cache is valid, we serve the data instantly from MongoDB (Fast & Cheap). If expired, we hit BigQuery once, update the cache, and serve.

The Result:

• My users get Unlimited Viewers for a flat rate.

• Dashboards load in milliseconds (no waiting for heavy SQL queries).

• My BigQuery bill doesn't explode.

Summary

It’s been a heavy week of coding, but the platform finally feels like a "Product" and not just a "Project."

We are currently in Open Beta.
If you want to try the Self-Healing SQL or the API Connector, come break it.

Link: Neoshift BI
Invite Code: BETA-A5C60983 (Unlocks the Basic tier for free during beta).

(Feedback on the API connector is especially welcome!)

Stop console.log-ing your JSON. Visualize APIs instantly instead.

Donald Wono — Wed, 04 Feb 2026 10:36:39 +0000

We've all been there. You need to check the data from a 3rd party API (Stripe, Weather, Crypto, or your own backend).

The Old Way:

Open Postman/Insomnia.

Send GET request.

Stare at a massive wall of nested JSON text.

Copy-paste it into a JSON formatter to make sense of it.

The New Way (What I built): I realized I was wasting hours just trying to "see" the data structure. So I added a generic API Connector to my tool, NeoShiftBI.

It treats any JSON endpoint like a database table.

How it works (The 30-second workflow):

Select Method: GET / POST.

Paste URL: (e.g., https://api.coingecko.com/...).

Auth: Add your Bearer Token (if needed).

Visualize: The AI scans the JSON response (even nested arrays) and auto-generates the schema. You can then ask questions like "Show me the price trend" and get a chart instantly.

Why I built this: I'm a developer. I hate building "Admin Dashboards" just to monitor a few API endpoints. This is my lazy solution to that problem.

It's currently in Open Beta (and free). If you have a messy API endpoint you want to test it on, give it a shot.

Link: https://bi.neoshift.ai/#/register
Invite Code: BETA-23D5BC9F

(PS: I just added Lemon Squeezy payments today, so the checkout flow is brand new. Let me know if it breaks! 🍋)

I have 8 users and Google Gemini is my Marketing Manager. Week 1 Reality.

Donald Wono — Tue, 03 Feb 2026 06:28:45 +0000

Hey Dev.to! 👋

I’m a developer, not a marketer. To be honest, I have no clue what I’m doing when it comes to selling software.

So, last Monday, when I decided to pull the trigger and release the public beta of my new tool (NeoShiftBI), I decided to hire the only marketing manager I could afford: Google Gemini.

I’ve been following its daily posting plans for LinkedIn, Twitter, and TikTok blindly.

The Week 1 Results:

Signups: 8 (mostly from spamming my friends on WhatsApp groups 😅).

Marketing Strategy: "Do what the AI says."

Current Status: Gemini told me to write a #watercooler post on Dev.to today to "build community," so here I am.

Why I actually built this (The Origin Story)

The previous company I worked at (an e-groceries platform) went under.

While we were alive, one of our biggest pain point was data fragmentation. We had our app data in MongoDB, our Warehouse management system used PostgreSQL, and financial projections in Excel/Google Sheets.

Although we had a data team, the requests always fell on us (the tech team) to build fragile ETL pipelines just to get a simple visualization for investors. It cluttered our backlog and killed our velocity.

Now that I have a lot more free time, I decided to fix it.

What I built:

I built NeoShiftBI to automate that "Tech Team" bottleneck. (I actually wrote a technical deep-dive yesterday on how the MongoDB schema inference engine works here, but the short version is below).

It connects to NoSQL/SQL/Sheets: No ETL required.

AI Schema Detection: It scans the data and understands the relationships automatically (no manual joins).

Text-to-SQL: You describe the chart you want ("Show me AOV by city") and the AI writes the query.

The Current Struggles:

Marketing: Clearly, 8 users isn't "Viral," but it's a start.

Payments (The Pivot): I was trying to get approved by Paddle, but they just rejected me because I don't have "transaction history." (The classic chicken-and-egg problem for new SaaS). So, today I am pivoting and applying to Lemon Squeezy instead. Wish me luck with their compliance team! 🍋

I’m giving out free upgrades to the Basic Plan for the beta cohort if anyone wants to roast my onboarding flow.
Link: https://bi.neoshift.ai/#/register
Beta Invite Code: BETA-C6423CDB

Wish me luck (and hopefully Lemon Squeezy approves me soon).

How I automated MongoDB JSON Flattening for Analytics (No ETL)

Donald Wono — Mon, 02 Feb 2026 09:13:22 +0000

I love MongoDB for its flexibility, but I’ve always hated building analytics dashboards on top of it.

The problem is always the same: Nested JSON.

If you want to visualize your data in a standard BI tool, you usually have to write a script or a complex aggregation pipeline ($unwind, anyone?) to flatten the arrays and objects into a tabular format.

I got tired of maintaining those ETL scripts, so I built a tool to do it automatically.

The Project: NeoShiftBI

I’ve been building NeoShiftBI, an AI-powered analytics platform. My goal for the MongoDB connector was simple: Connect a cluster and get a flat table instantly.

Here is a quick 90-second demo of how the auto-flattening and Incremental Sync works:

How it works under the hood

I built a custom schema inference engine (inferMongoSchema) to handle the translation to BigQuery. Here is the logic:

Sampling & Recursion: The connector fetches a sample of up to 100 documents and recursively analyzes each field (analyzeDocument) to determine the most common data type.

Type Normalization: MongoDB-specific types often break SQL pipelines. We normalize them on the fly:

ObjectId → converted to string

ISODate wrappers → extracted as clean timestamp

The Flattening Strategy: Since BigQuery doesn't allow dots in column names, we flatten nested objects using an underscore separator.

Input: {"user": {"address": {"city": "NYC"}}}

Output Column: user_address_city

Incremental Sync (CDC): Once the schema is set, we use a tracking column (like updated_at) to only fetch new or changed documents, preventing full-table scans on your production DB.

Try the Beta (Feedback Wanted)

I’m currently in Public Beta and I’m looking for developers with complex/messy MongoDB collections to stress-test the flattening logic.

If you want to try it out, I’m upgrading all Dev.to users to the Basic Plan ($29/mo) for free during the beta.

Link: https://bi.neoshift.ai/#/register

Invite Code: BETA-790DA393

Let me know if the parser handles your schema correctly or if you manage to break it! 🐛