Silkster

A step-by-step workflow for running a client discovery interview — from the core questions everyone can use, to using AI tools that turn your notes into a build-ready plan.

Most failed apps don't fail because the code was bad. They fail because the builder solved the wrong problem. A client interview is where you find out if you're building the right thing — and getting it wrong here makes everything downstream expensive to fix. Silkster supports the discovery process at every tier, starting with free access to the problem database, adding AI-assisted validation at Launch, and unlocking a full build-planning suite at Founder.

The Foundation

Even on the free tier, Silkster gives you context before you sit down with a client. Browse the

problem database

to see if the problem is already well-documented. Search up to 10 times per day. Save up to 3 ideas to reference during prep.

The Five Core Questions Use these regardless of tier:

1. What problem are you trying to solve? (Let them answer in their own words.)

2. Who experiences this problem, and how often?

3. What are you doing about it right now?

4. What does "solved" actually look like to you?

5. What's the cost of not solving it?

During the Interview Distinguish the stated problem from the real problem. Watch for workarounds — spreadsheets, informal Slack channels, manual processes — they show where the real pain is. Don't pitch during discovery.

After the Interview Document direct quotes, map the current workflow against the desired state, and record constraints explicitly: budget, timeline, existing tech stack, team size, end-user technical level. Before you finish, reflect your understanding back to the client, agree on a specific next step, and ask if follow-up questions are okay.

Sharper Prep and Validation

Silkster's Launch tier adds AI tools that make prep more structured and post-interview output more useful.

Before the Interview Generate a Validation Checklist (3/month) on the problem area. It produces a 4-week validation plan including customer interview questions — use these as the starting point for your interview guide. Use the Prompt Templates Library to structure your post-interview notes and brief.

During the Interview Go deeper with follow-up techniques. Ask "Can you walk me through exactly what happens when...?" to get concrete sequential answers. Use the Five Whys to get from symptom to root cause. Use silence deliberately — most people fill it with more detail.

After the Interview Run the Tech Stack Recommender (3/month). Input the client's skill level, budget, and timeline. It returns specific frontend, backend, database, auth, payments, and hosting recommendations with cost estimates, learning curve ratings, and tools to avoid. You now have a discovery brief, a validation framework, and a tech stack recommendation — all before writing any code.

From Interview to Actionable Plan

The Founder tier changes what you can deliver out of a single interview.

Before the Interview Run a Market Analysis (100/month) on the problem space. It generates a TAM estimate, competitor landscape, and market notes. This gives you informed questions about how the client differentiates from existing solutions and why those solutions have failed them.

After the Interview Generate a 90-Day Roadmap (5/month — flagship feature). It produces four milestones, week-by-week tasks with time estimates, financial projections (initial costs, monthly recurring, revenue projections, break-even), decision points with continue/pivot criteria, a "Do This First" immediate action item, and a curated resource list. This is the document you bring back to the client.

Keeping Momentum Use Adaptive Next Steps (10/month) to keep the project moving after the roadmap is in place. It generates 3-5 prioritised actions based on current blockers, recent progress, and goals — and adapts as the project evolves.

The Full Founder Workflow Market Analysis → interview → document the problem in Silkster → generate Roadmap and Tech Stack Recommendation → deliver a complete brief to the client. From first meeting to structured plan: hours, not weeks.

Every section uses the same five core questions. The interview discipline doesn't change based on subscription level. What changes is what you can do with what you learn. On Free, you walk away with a clear problem statement. On Launch, you add a validation framework and tech stack. On Founder, you deliver a market-grounded build plan. Start where you are. The tools will be there when you're ready.

This article was originally posted on Silkster.com

I gave myself two weekends to test a simple question:

With current AI tools, how much of a small SaaS can one experienced engineer realistically build?

Not a no-code experiment. I've been building software for decades. I wanted to see what happens when AI handles the mechanical implementation and I focus on architecture, constraints, and economics.

Here's what happened.

The Setup

Three tabs:

• Replit (codebase + hosting)

• Grok (early implementation planning)

• Claude (prompt refinement + structured audits)

Workflow:

1. Define feature

2. Use Grok or Claude to refine implementation approach

3. Paste structured prompt into Replit

4. Test

5. Fix

6. Repeat

Nothing autonomous. No magic agents. Just tight iteration loops.

What I Built

Silkster is a structured startup idea analysis platform:

• Curated idea database (65 ideas so far)

• Market size estimates

• Competitor summaries

• Build complexity projections

• Tiered AI-powered analysis

Stack:

• React + TypeScript

• Express + TypeScript

• PostgreSQL

• Stripe

• Redis (rate limiting)

• OpenRouter for LLM access

• Hosted on Replit

Time invested: two focused weekends.

Architecture Discipline: Separate ADD from Replit Markdown (replit.md)

Replit uses replit.md as an architectural control file. Its architect agent reads it to understand and approve structural changes.

If you mix iteration notes or speculative ideas into that file, you pollute the source of truth and risk losing information when Replit overwrites it.

So I split concerns:

• replit.md = current authoritative system state

• Separate .md = running Architecture Decision Document (ADD)

The ADD logged:

• Initial assumptions

• Model changes (Grok → Claude usage patterns)

• Cost guardrails

• Security hardening steps

• Schema and search changes

• Feature tradeoffs

The unexpected benefit: the ADD became structured context I could feed back into Claude after each major change to re-evaluate architecture, constraints, and risk.

It effectively created a rolling review loop.

This separation did three things:

1. Prevented architectural drift

2. Preserved a clean machine-readable contract for the agent

3. Enabled continuous AI-assisted re-evaluation

AI accelerates changes. Without decision logs, coherence degrades fast.

Documentation becomes structural integrity, not bureaucracy.

What AI Actually Accelerated

AI removed:

• Boilerplate writing

• CRUD scaffolding

• Auth wiring

• Basic UI generation

• API integration repetition

It dramatically compressed setup time.

What it did not remove:

• Architecture decisions

• Cost modeling

• Security design

• Data modeling tradeoffs

• Monetization logic

• Knowing when to stop adding features

The code is faster.

The thinking still matters.

Real Constraints I Hit

1. AI Costs Are Non-Trivial

After integrating AI analysis via OpenRouter, I ran test requests.

OpenRouter bill after a weekend: ~$15.

That forced immediate changes:

• Strict usage caps

• Tiered access

• Cheaper models for free tier

• Claude reserved for paid users

• Hard usage ceilings

AI features are recurring cost centers. You need guardrails.

2. Security Is Easy to Ignore (Until It Isn't)

I initially focused on features.

Then I ran a structured security review using Claude:

• Auth flow analysis

• CSRF exposure

• Token storage patterns

• Rate limiting gaps

• Input sanitization risks

It surfaced multiple weaknesses.

I then scanned it with Mozilla HTTP Observatory. It flagged missing headers and configuration issues.

Fixes included:

• Redis-based rate limiting

• CSRF protection

• Secure cookie flags

• Input validation

• Proper security headers

AI can identify risk patterns quickly.

You still need to interpret and implement correctly.

3. Database Performance Shows Up Fast

Basic LIKE queries slowed down around ~50 ideas.

Switched to PostgreSQL full-text search with GIN indexes.

Performance difference was immediate.

That wasn't an AI decision. That was experience recognizing scaling behavior early.

What Actually Changed in 2026

Historically, building this solo would require:

• Weeks of boilerplate

• Manual auth wiring

• UI iteration from scratch

• Integration debugging

• Infrastructure wrestling

Now, that layer compresses significantly.

The bottleneck moves to:

• Clear specification

• Economic discipline

• Risk management

• Decision quality

AI doesn't remove responsibility.

It removes friction.

And friction used to kill solo projects.

Mistakes

• Launched too late (MVP was ready by day 3).

• Delayed security hardening.

• Built non-core features (admin dashboards, referrals) too early.

• Lost time fighting Route 53 before switching to Cloudflare.

Nothing catastrophic, but easy traps.

The Real Takeaway

The interesting shift isn't that "AI can build apps."

It's this:

One experienced engineer can now operate with leverage that previously required a small team.

Not because AI is autonomous.

Because iteration cycles compress dramatically.

If you have architectural judgment, AI compounds it.

If you don't, AI accelerates bad decisions.

That's the divide.

Silkster is live at silkster.com (public beta).

Two weekends wasn't the impressive part.

The reduction in friction was.

This article was originally posted on Silkster.com