OctaK Edge

OctaK Edge is a research tool for people who trade or invest in Indian stocks. You look up a company and it returns a rating out of 100, the evidence behind that rating, and a trade plan with an entry price, a stop-loss and targets - or a refusal, when the setup is too weak to act on.

One rule governs the system: numbers come from code, words come from AI. Every score and price level is computed in TypeScript on the server, and the model only explains a verdict it did not produce.

The product concept and the scoring model are my collaborator's. I built the platform around them - the data layer, the analysis pipeline, the database, the access rules, the scheduled jobs and the three-app split. Two of us, pre-launch.

Most retail stock tools publish a number with no working shown. Ask a chatbot instead and it improvises a confident recommendation. Neither can be checked, which is the one thing that matters when the answer costs money.

OctaK Edge takes the harder position: every number traces to a deterministic module, and the model may only explain values it did not compute. Writing that sentence is easy. Holding it true across free data sources, a serverless time budget, five timeframes and a second app on the same database is the engineering.

My scope was everything between the scoring model and a product someone can use: fetching market data, running it through the engine, storing what it produced, deciding who sees what, and keeping it fresh on a schedule.

It shipped as a single Next.js app first - one deploy, and no service boundary to maintain while the surface was still moving. Once it stabilized I reviewed the whole codebase, wrote up twelve architecture decision records, and ran the split into three apps as a phased program rather than a rewrite.

Scope choices, recorded rather than rediscovered:

• No monorepo, and no separate repo for the schema or the shared package.
• No ORM - a typed client and per-table modules suit a dozen tables.
• No HTTP between apps, so no service mesh and no cross-app coupling.
• No API versioning with one first-party client - the seam is kept, not built.

One Next.js app, no separate backend. A single per-symbol pipeline is the spine: parallel fetch across independent sources, indicators, pattern detection, then a deterministic chain - component scores, timeframe-weighted blend, confluence, recommendation, trade setup, projection. Both the analysis and position routes call it, so the two surfaces cannot diverge.

Every data adapter is wrapped in a fail-safe cache. A thrown error becomes a typed "unavailable" for that field, and the response lists what was missing. No adapter ever substitutes a default.

Screening ~300 names per request is too heavy, so a cron precomputes a universe snapshot and requests only read it; its timestamp anchors determinism. Picks are written to an append-only forward log before the market resolves them, each stamped with the engine version and a hash of the exact scoring code.

Today it runs as three apps over one Supabase project - a credential-free landing site, the product, and an operator console - sharing only the schema and one published package.

• Deterministic Edge Score: seven component scores reweighted across five holding timeframes
• Trade plan with entry, stop, targets and reward-to-risk - or an explicit refusal when the setup is weak
• My Position: the same analysis adapted to a real entry price and quantity
• Edge Insight of the Day: a timeframe-specific screen over ~300 names, precomputed on a cron
• Append-only forward log: every pick recorded before the market resolves it

• A constraint that lives in a prompt is a suggestion. The determinism boundary held because the model was never given a code path that could write a number.
• Honest degradation costs less and is worth more than it looks. "Unavailable" beats a plausible default and deletes a class of bug nobody can reproduce.
• Deferring debt with an explicit revisit trigger turns rot into a decision.