logoalt Hacker News

panavmtoday at 4:15 AM1 replyview on HN

One thing I've noticed building domain-specific SaaS with AI assistance: the first few weeks feel like magic, but then the codebase becomes hard to maintain.

The issue isn't the AI output quality — it's that most builders (myself included, initially) use AI reactively. Ask a question, accept the answer, move on. No structure for maintaining context between sessions or verifying that new additions stay coherent with the existing system.

The builders who get the best results seem to treat Claude/Cursor more like a junior dev: useful, but you review everything, and you explicitly maintain shared context about the state of the project.

Domain-specific SaaS is actually a great use case for this because the problem space is bounded — you can give the AI a really tight context. "We are building scheduling and invoicing for pest control companies. Current architecture is X. Today we are adding Y." That specificity makes the output dramatically better than generic prompting.

Good luck with the build — the insight to go learn the domain in person before building is genuinely rare and gives you a huge moat.


Replies

tezclarketoday at 4:30 AM

It'll go further - bespoke software for the specific company. The exam training is a good example - people have different learning preferences so why can't we cater to that automatically if we already have all the data and context?

Voice input that actually works to reduce screen time and distractions while driving or wearing gloves on site. Understanding and reacting to parking availability in cities, prompting the technician to upsell in the way the system knows he's most comfortable with (so he actually does it).

Incumbents will have to base this on Salesforce and adapt it which is expensive and a grind. Even if they have appetite for that, retraining the technicians who are used to the existing way will be horrendous.