Abhilash Gopinath · Developer & Product Architect, SwingCora.
SwingCora is a production-grade stock screening platform for swing traders — 4,500+ US stocks, 40+ filters, an LLM prediction engine, paper trading, multi-tenant billing, and a full admin module. It runs live at swingcora.com. It was designed, architected, and built entirely by one person, using Anthropic Claude as co-architect and builder across six phased deliveries.
This is not a demo. It is not a prototype. It is a commercial SaaS product deployed to the cloud, handling real users, real subscriptions, and nightly automated processes. And it is the first fintech SaaS platform of its kind built 100% with AI assistance — from the first schema decision to production deployment.
What follows is the methodology that made it possible — and why it works for teams as well as individuals.
The Platform
SwingCora screens 4,500+ US stocks nightly against 40+ filters across five categories — Fundamental, Technical, Trend, Volume, and Graphical. Every filter maps to a pre-computed column in PostgreSQL, making screener queries single-row lookups rather than expensive joins.
Click any screenshot to view full size
Beyond the screener, SwingCora includes an AI prediction engine — powered by Groq’s llama3-70b model — that generates BUY / HOLD / AVOID signals with confidence scores and reasoning for every stock. A paper trading module lets users test strategies with $5,000 virtual credit, with nightly automated P&L resolution. An admin module with 12 screens allows feature toggling without code deployment. Two unique D3.js graphical filters — currently patent-pending — let users draw criteria directly on charts.
Integration Ecosystem
SwingCora connects to nine external services — each with a precise, single-purpose role. No overlap, no redundancy.
The Mindset Shift — AI as Co-Architect, Not Code Generator
The most important thing about how SwingCora was built is not any specific tool or technique. It is a fundamental change in how Claude is treated in the development process.
- Ask one-off questions with zero context
- Dive straight to code — skip architecture
- Treat every session as isolated and fresh
- Accept the first answer without challenge
- Sessions end with no recorded decisions
- Output works in demo, breaks in production
- Brief the AI fully — domain, users, goals, constraints
- Co-design architecture before touching code
- Maintain a Living Master Plan as shared memory
- Push back — demand alternatives and tradeoffs
- Challenge the first answer; ask for failure modes
- End every session by recording decisions made
- Design for production from Day 1, not for demos
The Methodology — Five Disciplines
1. Brief First, Build Second
Before asking anything technical, the full domain context was established: 4,500+ US stocks, end-of-day swing trading, PostgreSQL, multi-user commercial SaaS. The richer the brief, the better the architecture. SwingCora then demanded architecture before code — technology stack with reasoning, full database schema, folder structure. Every recommendation was challenged: what are the alternatives? What are the tradeoffs at scale? The stack was refined across multiple rounds of direct challenge before a single file was created.
2. Iterative Deep Dives — One Topic at a Time
Complex systems collapse when you try to design everything at once. SwingCora’s design process followed a strict rule: one concern per session. Broad architecture first, then database schema, then one feature at a time, then UX behaviour, then the Claude Code build prompt for that phase. Each session ended with an explicit decision summary — what was decided, what remains open.
3. The Living Master Plan
On Day 1, a Word document was started. Every architectural decision, schema definition, and data flow went into it. By the time build began, this document had grown to 120+ pages — covering technology stack rationale, all 31 database table schemas, multi-tenancy architecture, the full filter catalog, LLM prompt design, and folder structure conventions. This became the single source of truth for Anthropic Claude, for the architect, and for any future team member.
4. The Build Plan — Conceptualisation First, Then Six Delivery Phases
5. The Three Tools — Three Distinct Roles
- 120+ page Living Master Plan
- 31-table database schema design
- Architecture and feature deep-dives
- 170+ decisions tracked and recorded
- Legal pages: Terms, Privacy, Pricing
- Peer-reviewed the Master Plan
- Caught 13 schema issues before build
- Reviewed all Claude Code prompts
- Cross-checked Chat decisions
- Validated phase boundaries and scope
- Phase-by-phase builds from reviewed prompts
- FastAPI backend — 40+ screener endpoints
- Next.js frontend — screener, charts, trading
- Nightly batch pipeline — EOD → AI signals
- Admin, billing, email infrastructure
The Human in the Loop — Why Oversight Is Non-Negotiable
Anthropic Claude is a powerful co-developer. But it does not know your business, your product instincts, or the edge cases only live testing reveals. Two moments from the SwingCora build show exactly what human oversight is worth.
The problem with range sliders with two draggable handles is that when the user clicks on the line, either one will move — and probably that’s not what the user wanted. How in general does this situation get addressed in the UX world?
For all range sliders, highlight the active marker. User can click on it to activate, and then they can use it the way they want. Also the marker never crosses. — Abhilash Gopinath
Really elegant solution — and very well thought through. The click-to-activate pattern solves the ambiguity problem cleanly. This is arguably better than any of the standard industry patterns. This UX model should go into the prompt for Claude Code as a non-negotiable spec.
I was waiting for the scheduled Sunday run from Railway — it did not happen.
There is no railway.toml in the project at all. The nightly-batch service is configured as a regular worker — it only runs when a GitHub push triggers a new deployment. The Sunday run was never going to happen. Claude treated deployment as equivalent to scheduling — they are completely different things.
The Team Scale Model for IT Service Organisations — From One to Five
SwingCora was built by one person. But the methodology scales directly to teams. The same three reference documents that kept one architect consistent — CLAUDE.md (project context and conventions), DDL.md (all 31 table schemas), and API.md (endpoint patterns and auth) — can be committed to a Git repository and auto-loaded by every developer’s Claude Code instance.
The result: a junior developer on Day 1 produces code as consistent as the senior architect. For IT service organisations, onboarding becomes a matter of reading three files and running one command, not weeks of shadowing and tribal knowledge transfer.
Six Transferable Principles
The Bigger Picture — The Triad Model
SwingCora points toward something larger than one platform. It demonstrates what becomes possible when AI development matures from a productivity tool into a co-delivery model. The “Triad Model” — Product Owner, Senior Architect, QA Engineer — is a future where three people, working with Anthropic Claude, deliver what previously required a team of fifteen.
The principles in this post are not specific to fintech or stock screening. They apply to any domain, any stack, and any AI coding tool. SwingCora is the proof of concept. The methodology is the transferable asset.
Live platform: swingcora.com · Built with Anthropic Claude · Screenshots: SwingCora platform (May 2026)
Leave a Reply