- IndiaWhere it began
- CanadaWhere we're based
- WorldWho we build for
Million Dollar Studio
We build AI systems that turn expertise into scalable products.
- AI for judgement
- Software for execution
- Systems you own
Chapter 01 / Workflow X-Ray
See the work change shape.
Drag the slider to see how we deconstruct manual operations into clean, deterministic software pipelines.
Choose an example
NameOwnerStatusNotes—Open???Check
Manual and systematic workflow compared
01Inputs captured02Rules made explicit03Human approvals preserved04Operating asset packaged
Chapter 02 / Choose a path
Pick the door that matches what you need.
Some people want a product today. Some want software they own. Some need us to build around their workflow. Some want proof first. Start where you are.
ProductWant software now?Explore Products
Try the products, read the state labels, and see what already fits your workflow.
Best when you want a working thing to inspect first.AssetWant an asset to own?Own SoftwareBrowse finished websites and software assets, then customize the basics after purchase.
Best when you want speed, source, and a clear starting point.StudioWant us to build it?Build With UsBring the messy workflow. We map what matters, build the system, and hand you the keys.
Best when the work is valuable, repeatable, and still too manual.ProofWant proof first?See the ProofRead what is shipped, what is gated, and what still needs evidence before you trust the pitch.
Best when you want the label before the promise.Build With Us / Method
We turn the way your best people work into software your team can run.
Not vaporware. Not a generic automation layer. We make the inputs, rules, exceptions, interface, and ownership boundary visible before the system is called an asset.
No rigid timeline promise. Each phase advances when its evidence is reviewable; complexity determines the depth.
- 01Expertise becomes a workflow map.
Operational deconstruction
We follow one real, repeatable loop with the people who know it best. Triggers, inputs, decisions, exceptions, handoffs, and outputs become visible before anybody proposes software.
What becomes explicit- Trigger and required inputs
- Stable rules versus judgement
- Exceptions, owners, and outputs
We do not automate a process we have not understood.
- 02The workflow becomes testable modules.
System design and simulation
We separate intake, state, rules, review, and decision points. Representative scenarios expose data, interface, API, provider, and security constraints before production architecture is approved.
What becomes explicit- Module and state model
- Interface and data boundaries
- Representative scenario checks
A simulation is design evidence, not a production-readiness claim.
- 03Approved rules become inspectable software.
Code synthesis and verification
We implement the approved workflow in an appropriate, maintainable stack. Regression tests protect the stable path; review queues and audit trails keep uncertain cases visible to the accountable person.
What becomes explicit- Working interface and workflow state
- Regression and boundary tests
- Human review and exception paths
Frameworks and controls follow the approved scope, not a one-size-fits-all stack promise.
- 04The system becomes an operational asset.
Deployment and ownership handoff
We deploy to the agreed environment and hand over the repository, access, operating notes, and training named in scope. The signed agreement defines IP or licence terms, third-party dependencies, support, and exclusions.
What becomes explicit- Repository and deployment access
- Operating notes and training
- Agreement-controlled ownership terms
No blanket IP transfer, perpetual support, or provider guarantee is implied.
Chapter 03 / Product family
Five products, built in the open.
Move through the product cards. Each one says what it is, how real it is, and the safest next step - no fake users, revenue, or launch claims.
Swiss EphemerisReactFastAPI
Evidence receipt
- Current state
- Active
- Evidence type
- Public product surface
- Last reviewed
- 14 Jul 2026
- What this supports
- A public product surface can be opened and inspected.
- What this does not prove
- Customer usage, revenue, or universal commercial readiness.
Next.jsSupabaseFSRS
Evidence receipt
- Current state
- Gated
- Evidence type
- Deployed preview and source-owned state label
- Last reviewed
- 14 Jul 2026
- What this supports
- A preview exists while the public launch remains gated.
- What this does not prove
- Launch readiness, customer usage, or revenue.
Next.jsSupabasePublished Rules
Evidence receipt
- Current state
- Gated
- Evidence type
- Deployed preview and source-owned state label
- Last reviewed
- 14 Jul 2026
- What this supports
- A preview exists while the public launch remains gated.
- What this does not prove
- Launch readiness, customer usage, or revenue.
Next.jsTypeScriptRule Engine
Evidence receipt
- Current state
- Roadmap
- Evidence type
- Source-owned roadmap entry
- Last reviewed
- 14 Jul 2026
- What this supports
- The product direction is publicly described.
- What this does not prove
- A working product, delivery date, or commercial readiness.
Next.jsSupabaseMarket Data
Evidence receipt
- Current state
- Roadmap
- Evidence type
- Source-owned roadmap entry
- Last reviewed
- 14 Jul 2026
- What this supports
- The product direction is publicly described.
- What this does not prove
- A working product, delivery date, or commercial readiness.
Interactive product surface / Browser-local
Build a pipeline. See where the delay lives.
Turn a small operational route into three visible parts. Change the volume, rules, and review boundary; the model recalculates instantly.
- 01Separate the work into modular nodes.
- 02Expose the assumptions behind the result.
- 03Carry the example into a real diagnostic.
No contact details required to run or export the model.
Route builderDeterministic sandbox // v1
01
InputWeekly itemsRequests entering the route Drag or move
02
TransformerRule stepsDeterministic operations applied Drag or move
03
OutputHuman reviewItems held for a person Drag or move
Illustrative latency18 minsum of disclosed stage rules
Human checkpoints120% of items selected
Route deterministic Yeswith an explicit review boundary
Largest modeled stage: rule processing. Intake = 2 min / 20 items; rules = 4 min / step; review = 2 min / 10 selected items.
Illustrative structural example. No live systems, customer data, savings, or production performance.
Chapter 04 / Client proof
Real operators. Real shipped work.
These are public client testimonials from delivered work - not fabricated traction, not borrowed logos, and not a live revenue claim.
Read the full work notesMDS built our entire web presence end to end - a fast, polished, fully bilingual (English + Hindi) site that handles our industry’s regulatory nuance with real care, plus an inquiry-and-distributor pipeline that lands straight in our inbox. On spec, on brand, and genuinely professional.
Evidence receipt
- Current state
- Delivered work
- Evidence type
- Approved public testimonial and work note
- Last reviewed
- 14 Jul 2026
- What this supports
- The client approved this quote and attribution for public use.
- What this does not prove
- Revenue impact, current engagement status, or ongoing scope.
MDS reworked our catering menu for both print and online, refreshed our brand and social content, and is building us a custom command center to run the kitchen. They turned a manual, scattered operation into something organized and professional - and they actually get small business.
Evidence receipt
- Current state
- Delivered work
- Evidence type
- Approved public testimonial and work note
- Last reviewed
- 14 Jul 2026
- What this supports
- The client approved this quote and attribution for public use.
- What this does not prove
- Revenue impact, current engagement status, or ongoing scope.
Founder / Toronto
One founder. One studio thesis. Systems you can inspect.
Shrish Manglik builds MDS as a founder-led AI Systems Studio: product surfaces, client workflows, proof boundaries, and the public standard that every claim should match the evidence behind it.
Toronto-builtIndian-foundedBuilt for the world
Chapter 05 / Diagnostic receipt
Answer a few questions. Leave with a clearer map of the work.
Build a printable, browser-local first draft of what software could run, what AI could review, what people should decide, and what still needs an answer.
Useful output firstBrowser-localOptional founder review
No contact details required to create it.
Example workflowClient request → qualified next step
A rule-based first draft of where the work belongs.
Chapter 06 / Evidence receipts
Every important claim carries its own receipt.
Open the receipt on a product or client card to see its current state, evidence type, review date, and the boundary the evidence cannot cross.
Inspect the proof ledgerReceipt anatomyFive fields · one boundary
Receipts now live inside the claims they qualify.Open the full ledger
Chapter 07 / Ownership passport
Know what can be handed over before the build begins.
“Ownable” is not a blanket promise. Use this passport to see the access, files, documentation, and transition terms that a project can put in writing.
Source & repository
- Can include
- Repository access and the project source files named in scope.
- Agreement decides
- License or assignment terms, third-party dependencies, and exclusions.
- Not implied
- Universal IP transfer, resale rights, or perpetual support.