Custom Apps, APIs, And LLM Workflows Worth Building First
Custom software is most convincing when the first version removes a visible bottleneck. A small internal app, API bridge, or LLM workflow can create proof faster than a broad platform rebuild.
The question is not "what can AI do?" The better question is "which workflow should be faster, safer, or easier to operate next month?" That phrasing rules out half the bad first projects automatically: anything that cannot be measured in operational terms by the team that owns the work.
Strong First Candidates
Good first candidates have repeatable input, a clear user, and an output the business can judge.
Admin panels for manual back-office actions
API connectors between CRMs, payment tools, product databases, and spreadsheets
LLM assistants for support, onboarding, research, or internal operations
Document and form intake that feeds an app or workflow
Knowledge search with citations across internal docs and tickets
Reporting automation for leadership, finance, or customer success
These are software problems with business proof attached. They give the team something real to evaluate.
Each one has a default architecture shape worth committing to early:
Admin panel: Next.js (App Router) + tRPC or REST + Postgres + RBAC via Auth.js or Clerk. Resist the urge to use a no-code internal-tool builder once permissions and audit logs become real requirements.
API connector: A typed integration layer (TypeScript with Zod, or Python with Pydantic) per external system, plus an idempotent job queue (BullMQ, Sidekiq, Temporal, or pgmq). Webhooks should be authenticated, deduplicated by event ID, and retried with backoff.
LLM assistant: A thin service in front of OpenAI/Anthropic, with prompt versioning, structured-output schemas, response logging, and a per-tenant rate limit. Never call the model directly from the browser.
Document intake: OCR adapter + extraction model + validation rules + reviewer UI, as described in the document automation post.
Knowledge search: Hybrid retrieval (BM25 + vectors), reranker, citation-strict generation, and access-controlled chunks.
Reporting: Scheduled extract → transform → metric layer → AI commentary → approval → distribution.
The point is not that every project needs the full stack on day one. The point is that picking the default early avoids re-architecting in week three.
What To Bring To Discovery
The fastest first call includes screenshots, sample data, current tools, rough weekly volume, API access notes, the business owner, and the decision that should be possible after the PoC.
A more complete pre-discovery list:
3-5 screenshots of the current workflow (or a short Loom).
20-50 anonymized sample records or files.
A list of the SaaS tools and internal systems involved, with auth method (OAuth, API key, SSO).
Weekly and peak volume — items processed, users affected.
The named business owner and the reviewer/approver role.
Existing SLAs or error costs ("a misrouted ticket costs X hours; a missed invoice costs Y in late fees").
Constraints: data residency, on-prem requirements, deployment region, language requirements.
The shape of the decision after the PoC: integrate, expand, pause, change scope.
Without those inputs, the right next step may be a short readiness audit rather than a build sprint. The audit produces the same list as a written deliverable, which is usually faster than trying to assemble it during the kickoff of a build.
Why Start Narrow
Starting narrow reduces delivery risk and makes the first decision clearer. Once one workflow earns trust, the next sprint can add authentication, permissions, integrations, production deployment, or a broader product surface.
There is also a quieter reason: narrow scope keeps the team's attention on the operational details that determine whether the software is actually used. The retry behavior when an external API is down, the empty-state for the reviewer queue, the way confidence scores are surfaced to a non-technical user — these are the differences between a demo that wins a meeting and a system that is still running, with the original users, a year later. A first sprint built around them produces both.