--- title: "SnowOptix: the side project that led to Luminik" description: "SnowOptix started as a real Snowflake cost tool. The customer conversations mattered more than the tool and led me toward Luminik." canonical: https://prasad.tech/blog/snowflake-cost-optimization.html source: html generated_at: 2026-05-26T13:56:27.812Z --- [Home](/) / [Blog](/blog/) / Customer discovery Dec 2025 9 min read Customer discovery # SnowOptix: the side project that led to Luminik SnowOptix started as a real Snowflake cost tool. The customer conversations mattered more than the tool and led me toward Luminik. SnowOptix started as a narrow tool for a Snowflake cost problem I understood directly. It identified meaningful savings on the bill that started the project, then got into the Snowflake Native App Accelerator with help from Snowflake’s startups team. That validation was useful. The category still looked weak as a company wedge: small market, improving native Snowflake observability, crowded alternatives, and adoption that stayed smaller and more episodic than the recurring contracts I wanted to build around. The valuable outcome was the set of conversations it created. Those conversations surfaced a different problem: B2B teams were spending heavily on events, while the handoffs across attendee lists, enrichment, outreach, booth activity, and CRM attribution were fragile. That opportunity became Luminik. The argument in one paragraph I followed evidence from a working artifact. SnowOptix proved the cost pain was real, then showed the business limits around that pain. The calls pointed toward a larger and more urgent workflow problem in events: lists, enrichment, outreach, booth activity, and CRM attribution. A side project can be a research instrument when it creates conversations a thesis cannot. How SnowOptix led to Luminik Problem**Snowflake cost pain**I built a tool for a problem I understood directly. Artifact**SnowOptix**The side project gave me something concrete to show. Validation**Snowflake support**The Native App Accelerator and startups team helped me test the shape. Limit**Small market**Native tooling improved, alternatives were crowded, and contracts stayed small. Company**Luminik**Events had a clearer buyer, a bigger budget, and a deadline that made people move. ## How SnowOptix started At a previous role, the Snowflake bill kept growing. Queries were inefficient, warehouses were over-provisioned, and the data team was focused on shipping features before reducing costs. That happens often in fast-growing startups: speed comes first, efficiency gets attention once the bill is large enough. Snowflake exposes plenty of metadata about query performance, warehouse utilization, and storage patterns. The data is scattered across multiple system views, and turning it into actionable insights requires real engineering effort. So I built a tool. The first version was simple: scripts that pulled the metadata, ran analysis, and generated recommendations like “this warehouse is idle 80% of the time, consider auto-suspend” or “these 10 queries account for 60% of your compute costs.” **40%** Savings identified Measured on the Snowflake bill that started the project. **Native App** Snowflake Accelerator SnowOptix entered Snowflake's Native App Accelerator with support from the startups team. **Narrow** Market shape The category was competitive, increasingly served by native tooling, and weak for recurring contracts. What the evidence said The evidence was mixed. The original bill analysis found a concrete savings opportunity. Snowflake’s Native App Accelerator and startups team gave the project useful validation. Customer interest showed the pain was real, while the market shape showed why it would be hard to build the recurring-contract business I wanted. ## The conversations that changed the direction My first intention was to understand whether SnowOptix could be a real product. The calls gave me a sharper answer. Snowflake costs were real. The commercial pull was uneven. Several conversations drifted toward GTM operations: how teams prepared for events, followed up, and explained ROI after the spend was gone. I started asking for introductions. Those introductions gave me a second set of conversations with GTM leaders. The event-marketing problem (summarized from the calls) - **Before events.** Manual ICP matching, generic outreach, low meeting conversion. - **During events.** No real-time prospect intelligence, scattered note-taking. - **After events.** Delayed follow-up, broken attribution, unprovable ROI. - **Result.** Significant spend with no defensible way to measure impact. The pattern was consistent. Companies were spending heavily on events, and the operating process stayed manual across lists, enrichment, outreach, notes, and attribution. ## SnowOptix vs Luminik: the decision to pivot That left me with a choice. SnowOptix had real validation, including the Snowflake accelerator path. The business case still felt constrained. Snowflake’s own tooling was improving, the category was crowded, and the adoption I saw stayed smaller and more episodic than the contracts I wanted. Luminik had a clearer buyer, a larger budget surface, and a deadline that made the problem harder to ignore. | | SnowOptix | Luminik | | --------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | Market shape | Small category: Snowflake users with cost pain, many observability alternatives, improving native tooling. | Broader B2B pain across teams with sales targets and event budgets. | | Buyer urgency | Useful pain with inconsistent budget pressure. Savings mattered, with priority often below other data-team work. | Marketing leaders had quarter-by-quarter pressure to defend event ROI. | | Solution timing | Technically straightforward, increasingly served by platform-native observability. | LLMs made source, enrich, sequence, capture, and attribute more practical as one workflow. | Three lenses for the choice. The third one (timing) is the lens that ultimately decided it. > SnowOptix had validation. Luminik had a clearer buyer, larger budget surface, and stronger path to recurring contracts. ## Why following curiosity beats following plans I started with a problem I could feel in the work. The artifact changed the conversations I could have. Those conversations changed the market I understood. I trust that path more than a market map drawn before any customer has reacted to a product. ## Side projects as discovery mechanisms Five rules I would name earlier next time - **Build things that solve your own problems.** The best side projects start with genuine frustration rather than a market thesis invented in the abstract. - **Talk about what you are building.** Post on LinkedIn, Twitter, Hacker News, or wherever your potential users hang out. Treat it as an invitation to conversation. - **Have enough conversations to see the shape.** Ask about adjacent problems. Ask who else you should talk to. Listen for specific follow-up questions. - **Track conversation quality.** If one topic produces polite interest and another produces specific workflow detail, pay attention. - **Let the project finish its job.** Once it has taught you enough, moving on can be the right decision. The bigger lesson Planning is useful once the problem is known. Discovery work needs a different posture: build something concrete, show it to people, notice which questions keep coming back, and let the evidence update the target. SnowOptix became the learning artifact that made Luminik clear enough to pursue. ![Prasad Subrahmanya](/assets/images/header/prasad.jpeg) ## Prasad Subrahmanya Builder and operator at Luminik. Built Aura at Bain to $3.6M ARR, co-founded Mainteny through its $2.7M seed, and helped build the initial product and team. [LinkedIn](https://linkedin.com/in/prasadus) [GitHub](https://github.com/prasadus92) [ Back to blog](/blog/) ## Filed under Customer discovery SnowOptixLuminikcustomer discovery ## Related notes [**Separating agent work from founder work**Why I moved recurring agent work out of my daily workspace, what the boundary controls, and which approvals still stay with me.](/blog/dedicated-mac-mini-solo-startup.html)[**Selling the workflow before the software**I delivered Luminik manually before building the product surface. That work showed which event workflows repeated and which steps belonged in software.](/blog/selling-before-building.html)[**Alfred: how I run repeated work as a solo founder**How I use Alfred to turn repeated company work into plans, summaries, draft replies, and pull requests I can review before anything ships.](/blog/alfred-solo-founder-operating-system.html)