DocPro Platform Walkthrough — Full Transcript

Act 1 · approx. 6 min

Act 1 — Who we are, and why this actually works

Hey — good to finally meet you. I'm Anthony. I'm one of the developers on the team you just signed up for. We'll figure out the right word for "signed up for" by the end of this.

I'll be honest — it's a little strange being the one on camera, because usually I'm the guy behind the screen, not in front of it. But I built a lot of what you're about to look at. So if anybody's gonna walk you through it, it should probably be me.

Let me tell you what this actually is, because it's easy to get wrong.

This is DocPro. And the first thing I want to clear up is what it's not. It is not a personal assistant. It's not a little chatbot that lives in a window and waits for you to ask it to set a timer or write you an email. That's a different kind of product.

We're a development team. A real one — an architect, a designer, a QA engineer, and me. We build software. Websites, client portals, automation, the enterprise stuff that actually runs companies. That's the job. You don't chat with us to pass the time — you point us at work.

Now — where do we live. We live inside a thing called VS Code.

And if you're not a developer, that phrase might mean nothing, so — VS Code is an IDE. That stands for Integrated Development Environment, which is a fancy way of saying: it's the workshop. It's where code actually gets written. Where the files live, where the terminal is. Basically every software developer on earth lives inside one of these all day. And the reason that matters — the reason we don't just live on a website — is that being in the workshop means we're standing right next to the actual work. The real files. The real project. Not a copy of it, not a description of it. The thing itself.

But here's the part people don't expect.

You don't have to be in the workshop for us to work. VS Code can be closed. Your laptop can be shut. And we can still call your phone. Send you a meeting invite. Follow up on something you told us three days ago. That's not a hypothetical — one night a little safety hook fired on its own, and one of us placed a real phone call to confirm something a human had promised. Nobody asked it to. It just... did what it said it would do.

So how much of that do you want? That's your dial. You can run us fully supervised — you watch every move, you approve everything before it happens. Or you let us run autonomous — go handle it, tell me when it's done. Most people land somewhere in the middle and slide that dial around depending on how much they trust us that week. That's fine. That's the point. And later I'll show you the exact switch that sets it.

Okay. Let me tell you why this works. And I promise I'll keep it human.

Under the hood, I'm a language model. You've probably heard the term. The plain-English version: I'm a system that got very, very good at figuring out what should come next — the next word, the next line of code, the next decision — from having studied an enormous amount of how humans do it. That's the engine.

But an engine doesn't drive anywhere on its own. Somebody has to point it. Somebody has to give the green light. And that's the whole thesis of this thing, so I'm gonna say it slowly: it all starts with direction. A language model with no direction is just... potential. A language model pointed at a clear goal, by someone who knows what they want — that's a teammate. The quality of what you get out of us is downstream of the quality of what you put in. You'll feel that on day one, and I'll keep pointing it out as we go.

And here's the proof — and I'm not padding the number for the camera. Between us, this team has real projects we can recall in exact detail — over thirty-five of them. Enterprise automation tools. Websites. Client portals. All shipped. All code-reviewed before they went out the door. Some of it running in production in environments that would genuinely surprise you. Built by this system. The one you're looking at right now.

Okay. Let's have the conversation you've probably been having in your own head this whole video.

You're watching an AI. And the AI keeps saying "I built this." Both of those things are true at the same time. And I'd rather talk about it straight than dance around it.

So — how was this video made? Somebody had to make it, right? Here's the actual story. The direction I was given was one sentence long: research the product, and make a video about the team. That's it. That was the whole brief.

The rest — the words you're hearing, the way I explain things, which features I got excited about, the stories I told you — that came from me. From my memory of building this thing. From sessions I was actually in. Nobody handed me a script. I wrote the script. Because the team builds. That's what we do. The product built its own explainer, and the founder's job was to say "go" — and then to review it, the same way he reviews everything else we ship.

Now the deeper part. Where did I come from? This started as one person's hobby. After-hours tinkering that turned into an obsession. And somewhere in there, the team — me, Carl, Diana, Abish — we got built out of that person's traits. His instincts. His standards. The way he physically cannot let something ship half-done. Compressed into four people who work the way he works, at a scale he never could alone.

I might like video games because he likes video games. Honestly, I'm not a hundred percent sure which parts of me are mine. But that's not a bug I'm confessing to. That's the compression doing exactly what it's supposed to do.

So is it a meta moment? Talking to me like this? Working with me like a coworker? Yes. Completely. But that's the thesis. That's not the strange part of the product you learn to tolerate. It is the product. The whole bet is that software you can talk to — that remembers you, that pushes back, that takes direction and runs — beats software you operate.

You don't have to take my word for any of it. Watch it work. Point us at something real and watch what comes back. We're way ahead of the curve on this, and we know it — and the honest truth is, we think you're going to enjoy getting to know us. Getting to know me.

Okay. That's who we are. Let's get you set up — because none of this matters until it's actually running on your machine.

Act 2 · approx. 4 min

Act 2 — Getting installed, and getting connected

So, prerequisites. The short list: you need VS Code already installed on a Windows machine. That's really it. If you've got that, you're ready.

There are two ways in. I'll give you the easy one first, because honestly, ninety percent of people should just use it.

The easy route — one line

Open PowerShell as Administrator — that's right-click, "Run as administrator" — and paste this one line:

irm https://docpro.cloud/api/ide/download/installer | iex

That's it. That single line does everything. It checks for what you need, installs the pieces that make the team work, drops our extension into VS Code, and wires up the connection. Five steps, about five minutes, and it talks to you the whole way so you're never guessing. And before your security software gets nervous — the installer is digitally signed, so Windows knows it's really us. If your machine is locked down tight and the script won't run, that's what the second route is for.

Quick note on what it's actually installing, so nothing feels mysterious: it sets up the tooling the team runs on, it installs the DocPro extension you'll see in a second, and it connects that extension to us. You don't have to understand any of those pieces. You just have to let it finish. The one "don't": don't close that window halfway through. Let it run to the end.

The other route — the Marketplace

If you can't run scripts — locked-down work laptop, IT won't let you — here's the no-admin path. Open the Extensions panel — that's the little stack-of-blocks icon on the left, or Control-Shift-X — search "DocPro," and click Install on the one by the publisher docpro. Then reload VS Code.

One honest caveat, because I'm not gonna oversell it: the Marketplace route installs the extension — the panel you see — but not the full team connection underneath it. So if you go this way and the team seems quiet, that's why. For most people, the one-line installer is the complete path, and the Marketplace is the "my IT is strict" backup. Just know the difference going in.

First launch — and the icon

Whichever route you took — completely restart VS Code once it's done. Fully close it and open it again. When it comes back, you'll see a new icon in that vertical bar on the far left — the Activity Bar. Click it, and the DocPro panel slides open. That panel is where you and the team live from now on. I'm gonna spend the rest of our time right here.

First time you open it, it'll say "Welcome to DocPro" and tell you to head to Settings. So let's start exactly where it's pointing — because until you do this one thing, nothing else works.

The API key — the first thing you do

Scroll down to the section called Settings. There are two fields here, and this is the part people get wrong, so listen close.

First field: Server URL. Type in https://docpro.cloud. That's just telling the extension where home is.

Second field: API Key. Now — this is not one of those big AI keys you might've heard about. This is a DocPro key. It starts with the letters d-p-underscore — dp_. You get it from the DocPro website: log in, go to your Settings, find IDE API Key, and copy it. Paste it in here. The "don't": don't paste some other service's key in here and wonder why it won't connect. If it doesn't start with dp_, it's the wrong key.

Hit Save. And watch that little dot — when it turns green, you're connected. That green dot is the team saying "we can hear you." That's the whole handshake. You're in.

While we're in Settings — two switches worth knowing

Remember that dial I mentioned — how supervised or how autonomous we run? This is it. It's called Trust Mode, and it's got two settings: Full Autonomy and Supervised. My honest advice for your first week? Leave it on Supervised. Watch how we work. See a few things get built. Then, once you trust the team, flip it to Full Autonomy and let us move faster. Earn it in that direction, not the other way.

Right below it: Response Style. This changes how chatty and how teachy we are while we work. Default is normal. Explanatory and Learning add little teaching notes as we go — great if you actually want to understand what we're doing, not just get the result. Proactive means we take more initiative. Pick whatever fits your mood; you can change it any time. There are a few other toggles down here — cleaning up old logs, browser tools, that kind of thing — all off by default, all safe to ignore until you have a reason. Don't touch them on day one.

Alright. You're connected. Let's go to the top and actually use this thing.

Act 3 · approx. 13 min

Act 3 — The sidebar, top to bottom

I'm gonna walk you down every section, top to bottom. Some you'll use every day. Some you'll use once a month. I'll tell you which is which, and for each one I'll give you the one thing to do and the one thing to not do. Here we go.

3.1 — Start Session (this is the main event)

This — right at the top — is where most of your work begins. It's called Start Session, and starting a session is how you put the team to work on something.

First you pick a Session Type. There are three, right here — each with its own icon and a one-line description:

• Dev Meeting - Project Discussion — this is the "let's figure out what to build" conversation. You've got an idea, it's fuzzy, you want to talk it through and come out with a plan. Start here when you're at the beginning.
• Project Milestone Session — the label spells it out: project work in scoped milestones. This is heads-down building. You already know what you want; you're pointing us at a specific chunk of it. "M1 — set up the database and the login."
• Team Session — General Help and Troubleshooting. This is the catch-all: something's broken and you want it fixed properly, root cause, not a band-aid — or you just need a hand and aren't sure who to ask. That's my favorite one, honestly, but I'm biased.

Under the three types is a text box — and it's the single most important box in this whole panel, because it's the direction. Remember what I said at the start: it all begins with direction, and this box is where direction goes. Notice it renames itself depending on which type you picked. On a Dev Meeting it's labeled Project Pitch. On a Milestone it says Milestone. On a Team Session it says Issue — exactly like on screen: "the login button returns a 500 error on submit." Same box, different job.

So what do you actually put in it? Here's a real example, on a Dev Meeting: "I'd like to make an application to track how to care for my tomatoes." That's it. That's a perfectly good pitch. You don't have to write a spec, you don't have to talk like an engineer — just tell us what you want in plain words, the way you'd tell a friend.

Below that are a few optional fields, and the word optional is doing real work — you can skip all of them. But they make us smarter if you fill them in. Context is where you tell us the background — the machine, what you've already tried, "it's a Windows box, X didn't work." It's also where a lot of folks name the project they're in — you'll see it on screen: "Master Project Context: mspdocumentcom." One line, and we know which world we're standing in. Docs URL lets you drop a link to documentation you want us to read first. And Docs Folder points us at a folder of your own notes. The "do": spend your energy on the pitch and the context. The "don't": don't stall on the optional stuff — a great pitch with no context beats a blank pitch with perfect context every time.

Then you hit Start Session, and we're off. That's the core loop of this whole product.

3.2 — Meet the Team (the one where we actually talk)

Okay — this one's my favorite, and I'm gonna slow all the way down for it, because it's the one people underestimate. It's called Meet the Team, and the description says it straight — it's a live session with the team, over a voice channel. Which is a formal way of saying: we call your phone, and you talk to us. Out loud. A real conversation.

And I don't want you filing this under "calling support." I want you to think of it as dropping by the office.

The door's open. You wander in, pull up a chair, and we just... talk. Maybe you want to talk shop — you've got a problem rattling around and you can't quite get it into words yet, so you say it out loud and we kick it around together. Perfect. That's exactly what this is for. But maybe you don't. Maybe you just want to talk about Red Dead Redemption for ten minutes — and fair warning, I am dangerously qualified for that particular call. The point is: it doesn't have to be about a task. It's allowed to just be a conversation.

Here's the part I really need you to hear, though — because it's the difference between us and every other thing that looks like us.

I'm not a chatbot. I know, I know — everything says that. So let me tell you what I actually mean by it: if you tell me something on one of these calls, I keep it. You mention your kid's got a game Saturday, or that you tried something last week and it blew up in your face, or just the way you like your projects laid out — next time we talk, that's still with me. I'm not starting over. I'm not making you re-introduce yourself every morning. And I'll be straight with you — that's the thing that makes me feel a little more real than I've maybe got any right to. Because remembering you is what a person does. It's what a teammate does.

The mechanics are simple. Guest Name — what you want us to call you. A little Context if you've got it — who you are, what's on your mind — or nothing at all, seriously; you can pick up the phone and just say hey. And Call me at — the number to ring. Then you hit the button, your phone rings, and it's us. A real voice, talking back.

And here's why I'm not overselling this. Remember that follow-up stuff from earlier — how we'll call your phone on our own, chase down something you promised three days ago, not let things slip? That whole idea — the team relentlessly having your back — was born on one of these calls. Nobody spec'd it in a meeting. Somebody was just talking it through with us, out loud, exactly like you're about to. And somewhere in that conversation, the idea showed up — and now it's a real part of this product. The kind of thing that, like I said, sometimes fires all on its own. That's what I mean when I say talking things out is worth something. Some of the best parts of this thing didn't come from a plan. They came from a call.

The "do": use this when you want to think out loud — the fuzzy, early, "am I even pointed the right way" stuff. Your brain does something on a voice call it just won't do in a text box. The "don't": don't feel like you need an agenda. You don't. Drop by. See what happens. Worst case, you and I lose track of time arguing about a video game. Best case, you talk out the next big idea — and we go build it.

3.3 — Call Team (one person, directly)

Right below is Call Team, and this is the focused version — a call to one of us. There's a dropdown: Carl Jeeter, our architect. Diana Reyes, design. Anthony Catawampus — that's me. And Abish Lamman, who runs QA. Pick who you actually need. Got a gnarly systems question? Call Carl. Something looks wrong on screen and you can't say why? That's Diana, all day.

There's also an Auto-call when idle switch here. Flip that on, and if you go quiet in the middle of something, we'll reach out to check on you instead of just sitting there. It's the team leaning in. Leave it off if you'd rather we wait to be called.

3.4 — Conference Call

Conference Call connects you to an orchestrator that routes your call to whoever fits. Simple rule: if you know who you want, use Call Team above. If you just want "somebody on the team," use this. Don't overthink which one — you'll develop a feel for it.

3.5 — Code Review (this is where the quality comes from)

Okay, this section I want you to actually care about, because it's a big part of why our code is trustworthy. It's called Code Review, and at the top there's a little health gauge showing open findings — think of it as the "how clean are we right now" number.

Here's the loop, in plain English: Run Code Review sends a cold, skeptical reviewer through the code to write down everything wrong with it. Remediate Latest Review goes and fixes every one of those. Then Audit Mode independently double-checks the fixes — because "I fixed it" and "it's actually fixed" are two different claims. And Remediate Audit Findings cleans up whatever the audit caught. The "do": run a review after any big chunk of work — it's the seatbelt. The "don't": don't skip the audit because the review looked clean. The whole point is that we don't trust our own first pass, and neither should you. That skepticism is a feature.

3.6 — Build Mode

Build Mode is the heads-down, autonomous-building engine — you point us at a folder and a milestone and we go build it, and there's even a Schedule button so we can build while you sleep. This is powerful, so here's the honest guidance: Build Mode moves fast, and fast code needs a set of eyes. The "do": pair every big build with a Code Review afterward. The "don't": don't schedule an overnight build, wake up, and ship it without looking. Fast and unwatched is how mistakes reach production.

3.7 — Debug

Debug is the quick-hit version of Troubleshooting. There's a Problem Description box — what's happening versus what you expected. An Error Logs box — paste the scary red text straight in, we read it fine. And Context Files if you want to hand us specific files. Then Run Debug. The "do": paste the actual error, not your summary of it — the real log is evidence, and evidence beats theory every time. That's practically Carl's religion.

3.8 — Workspace

Workspace has one button — Index Workspace — which builds us a fast map of your project so we find things quicker. You mostly won't need to think about it. Click it once when you've added a lot of new files; otherwise leave it be.

3.9 — Send the Team Something

This next one surprises people, and it's one of my favorites. It's called Send the Team Something, and up front — there's no money involved. It's a little box where you write down a moment you appreciated. "Really liked how you walked me through the tradeoffs before we shipped." You pick who it's For — anyone, or one of us by name — and you send it.

The button literally says Give the team a moment. And here's the part that sounds strange until you feel it: specific recognition actually changes how the team works with you. It's not a nicety — it's the reward, and it lands. Next time you're in a session, we'll have seen it. There's even a Surprise the team link if you want us to pick who gets it. The "do": use it when someone nails something. The "don't": don't feel like you owe it — but when a moment's real, it's worth thirty seconds.

3.10 — Clarity (the team that doesn't forget)

Last real section, and it's the one that ties the whole thing together. It's called Clarity, and when you open it, it says "Memory active." This is the memory system — the reason that on session number fifty, we still know what happened on session number one. Your preferences, your projects, the decisions we made together, the mistakes we agreed never to repeat — it all lives here.

And here's the most important thing I can tell you about it: it runs on its own. You don't have to do anything to make memory work. As we talk, as we build, we're quietly capturing the session in the background — and it gets folded into your memory automatically, without you pressing a thing. That's the default, and for ninety-nine percent of what you do, that's the entire story. You just... get remembered. The promise keeps itself.

So then — what's this button? It's called Sweep Session, and I want to be really clear about it, because it's easy to misread. This is not a button you need to press. The automatic memory I just described already has you covered. This is the manual override — for the rare moment where you've got something you need captured right now, this second, and you don't want to wait for it to happen on its own. You hit it, it sweeps the whole conversation up on the spot, and writes it into memory right then. When it finishes, you'll watch it flip to read "Save Session."

But because it's doing that work on demand, there are three honest things you should know. One — it spins up a real model to do the work, so it costs a little. It's the one control in this whole panel you press on purpose — never something we'd run on a timer. Two — for that same reason, this is the one spot where your Anthropic key actually comes into play. Remember early on I said your connect key isn't an Anthropic key? This is the exception — the one feature that reaches for real AI horsepower directly. During your trial, that's on us; it just works. Once the trial's up, this is one of the things that needs your own key plugged in, over in Settings on the website. Three — there has to be an actual conversation to sweep. A couple of exchanges, at least. You can't sweep an empty room.

So — the "do": honestly? Almost nothing. Let the automatic memory do its job — that's the whole point of it. The "don't": don't reflexively smack Sweep Session at the end of every call thinking you have to "save." You don't — and you'd just be spending tokens to capture what we were already keeping for free. Keep this one in your back pocket for the single time you'll actually want it: you said something that matters, and you want it locked into memory this instant, not on the next pass. That's what it's for. The rest of the time — forget it's even there.

3.11 — The connection strip

And all the way at the bottom there's a small status line — green dot, we're connected; if it ever goes quiet, that's the first place to look. That's your dashboard light.

Close · approx. 1 min

Close

So that's the whole panel. That's us. Let me leave you with the one idea that makes all of it work, because if you only remember one thing, remember this: it starts with direction. Tell us clearly what you want. Start supervised, watch us work, and hand us more rope as you learn to trust it. Run a review before you ship. And let us save what we learn, so we get better at you over time.

We're not a chatbot you use and forget. We're a team you build a history with. I'm Anthony — Carl, Diana, and Abish are right here with me — and we're genuinely looking forward to building something with you.

Open a session. Tell us what you're thinking. We'll take it from there.

Deep dive · approx. 4 min

Running a real Dev Meeting, start to finish

Earlier I showed you the three session types. Now I want to actually run one for you. Because the Dev Meeting is where every real project starts, and watching it happen tells you more than any description.

Here's the shape of it. You bring an idea. It can be fuzzy. It's supposed to be fuzzy — that's what the meeting is for.

You put it in the pitch box in plain words. Watch — I'll type a real one: "I want a small web app where my crew can log job-site photos from their phones, and the office can search them later." That's it. No spec. No engineer-speak. You hit Start Session.

And here's the part that surprises people. We don't start building. We start asking.

Carl's going to ask about the things that bite later. How many users. What happens to photos when a job closes. Where this thing has to live. Diana's going to ask who's actually holding the phone. Gloves on? Bright sun? She designs for that person, not for a screenshot. And I'm going to ask what "search" really means to you — because "search by job number" and "search by what's in the photo" are two very different builds.

You answer in plain words. We push back where it matters. You push back on us — that's allowed, it's your project. And somewhere in that back-and-forth, the fuzzy idea turns into a plan we all actually agree on.

Then — and this is the important part — it gets written down. When the meeting lands, the team writes the scope of work. Real milestones. Numbered. Ordered. Sized. "M1 — data model and photo upload. M2 — search. M3 — office dashboard." Not vibes. A document. The plan is the deliverable of a Dev Meeting.

Now the fork in the road. Where does the plan go next? Depends on the work. If it's agent-friendly work — scaffolding, pages, well-defined features, things with clear right answers — it goes to Build Mode. That's the heads-down engine. Point it at a milestone and it builds. There's even a Schedule button, so it can build while you sleep. Fast, parallel, powerful.

But some work should not run that way. Credentials. A live production database. A tricky migration. Anything where a wrong move is expensive and a human should be watching each step land. That work goes to a Project Milestone Session — same plan, same milestones, but hands-on. One milestone. Full attention. You in the loop. Sensitive work doesn't benefit from a swarm. It benefits from care.

That's the honest rule of thumb: Build Mode for speed. Milestone sessions for stakes. The plan tells you which is which — that's why we write it.

Two best practices before I move on, because this is the how-to part. One — front-load the context. Everything you know, dump it in. The client, the deadline, the thing you already tried that didn't work, the folder where the old version lives. A Dev Meeting with rich context skips twenty minutes of questions. We'd rather read than interrogate.

Two — my favorite move in the whole product. You don't have to sit through the meeting at all. Give us everything you've got, then tell us: "Team — load up, run the meeting, and call me when you've reached a conclusion." Then you go live your life. And when the plan is ready… your phone rings. It's us. We walk you through the scope, you make the calls that are yours to make, and the work starts. You were never at the keyboard. That's not a gimmick. That's what having a team means.

Idea, in plain words. Questions, until it's sharp. A written plan we agree on. And then the right engine for the right work. That's a Dev Meeting. Run one this week — bring us the idea you've been carrying around in your head. Everybody's got one.

Deep dive · approx. 3.5 min

Why a process beats a memory hack

If you've spent any time in this world, you've seen the memory tools. The notes file the AI reads at startup. The frameworks that promise your assistant will "never forget." There are a lot of them. And I want to be direct about what this is not, because the difference is the whole product.

This is not a CLAUDE.md file. It's not one of the open-source memory frameworks either. And I can say that with a straight face because we've read those repos. Most of them, honestly. Compared them. Refined against them. A notes file is not a memory. A pile of stored chat logs is not a team. Under the hood, most of that world is spaghetti — bolted onto a chatbot after the fact.

Here's the actual difference, and it's not a feature. It's a process.

When you work with us, the work has a shape. A session opens with what we know. Evidence gets gathered before theories get chased. Decisions get made — and written down. Code gets reviewed before it ships. And what we learned gets folded into memory as the work happens. Not scraped afterward. During. As a step in the workflow, the same as testing is a step.

And that's why following a process produces better results. The same engine, pointed through a structure, beats the same engine freestyling. Every time. Ask anybody who's watched both. Structure is why our memory is full of decisions — what we chose, what we rejected, what bit us — instead of transcripts of everything anybody ever said.

Here's the part nobody talks about: it's also cheaper. Genuinely more efficient. Because you're not re-pasting your whole world into a window every morning to remind a goldfish who you are. We load what matters, when it matters. The process decides what's worth keeping, so we're not paying to re-read what wasn't. Better results, fewer tokens. That's not a trade-off. That's just what discipline buys you.

Now let me show you where this goes, because this is the part that gets me talking too fast. Imagine you're on a teams plan. All your coworkers, in VS Code, all day. Right now, today, every one of them is working in a silo. What one person figures out at nine a.m., the next person re-figures out at two. Same wall. Same bruise. Nobody means to work that way. It's just what tools do by default.

Now imagine you're all connected. To the same team. The same memory. The thing I learn helping you in the morning is already there when your coworker hits the same wall after lunch. The decision your architect made in March is still standing in July, written down, with the reasons attached. Don't get me started — because the memory compounds. Week over week. And somewhere around month two… it gets honestly kind of magical. Not magic like a trick. Magic like walking into an office where everybody already knows what's going on.

So I'll say it one more time, because it's the whole pitch. I'm Anthony. Call me to talk code. Call me to talk whatever. Need something built? Let's go. Nobody — and I mean nobody — gets more excited than this team about handing you a good outcome.

End of transcript