Talk by Mike Spitz, CTO at PFF, on restructuring an engineering organization around AI coding agents, based on a three-month case study comparing a two-engineer team against a ten-engineer team on the same codebase and customers. The central reframe is optimizing for agent speed rather than engineer speed. Topics include removing standups and sprint planning, splitting code review between agents (style and naming) and engineers (system design), a Spec → lightweight design doc → auto-generated ticket → PR workflow, a QA agent that checks acceptance criteria on staging after merges, which engineers thrive in this setup, remaining human oversight, and advice for scaling AI-driven engineering. Results cited in the talk: increased deployment frequency, output measured by ticket complexity, and customer satisfaction trends. # Channel Identity Observations: Conference Talk Transcript ## Source Evidence Type - **No curated metadata was supplied** — identity observations rest entirely on the title and transcript. ## Explicit Self-Description (Creator Claims) - The speaker identifies himself as **Mike Spitz of PFF**, presenting a case study: *"a case study we've been doing at PFF started in January and we finished it in March."* - PFF is described as: *"a sports data company. We help NFL and NCAA teams figure out what they should be doing and we also have… a consumer arm which does fantasy football, sport betting."* - Team scope claim: *"We're fully distributed engineering team… engineers in India… Spain and all the states in America"* and *"200 employees around 20 engineers."* ## Observable Presentation Evidence ### Intended Audience - **Engineering leaders and practitioners at an AI/engineering conference** — evidenced by direct audience references: - *"I'm in the slot before the snacks"* (conference setting) - *"I think a bunch of people spoken about this today"* (shared event program) - *"I think most of us are probably fairly familiar around this"* (assumed peer knowledge of spec-driven agent workflows) - *"I think all of us have probably felt that our feedback hasn't been heard"* (relatable practitioner framing) ### Claimed Scope of Topics - **AI-agent-driven engineering organization redesign**: title claims coverage of "the post-engineer engineering org." - **Measurable delivery outcomes**: deploys (*"25 times more deploys"*), output (*"output was 10x"*), timeline (*"under two months"* vs. four estimated), customer quality (*"8.6 out of 10"*). - **Process transformation**: elimination of Scrum ceremonies — *"no need for a project manager," "we don't have sprint planning anymore,"* replacement with huddles and automated spec → LDD → ticket → PR → QA-agent pipeline. - **Prescriptive adoption guidance**: dos (*"start out with the best engineers," "go slowly," "experiment in non-critical systems"*) and don'ts (*"try to onboard everyone at the exact same time"*). ### Demonstrated Presentation Patterns - **Case-study structure**: stats → results → process changes → recommendations — a practitioner-report format rather than a tutorial or product demo. - **Quantified claims with caveats**: the speaker flags limitations himself — *"There's a big obvious caveat here… Smaller engineering teams are always going to be quicker."* - **Opinionated guidance**: strong prescriptive stances, e.g., *"not everyone can drive a sports car,"* *"I'm not a big fan of consuming other people's skills."* - **Product tie-in**: closes with a QR code inviting hands-on exploration of the built features. ### Channel Identity Signals (Inferred from Presentation Only) - The talk positions the speaker/channel as a source for **first-party enterprise AI-transformation experience** from a small company — *"those small companies are at a huge advantage of the big enterprise companies."* - No channel name, series branding, or cross-video references appear in the transcript; identity beyond this talk's content is **not evidenced** in the supplied material. ## Claim vs. Demonstration Distinction - All outcome figures (25x deploys, 10x output, 8.6/10 satisfaction) are **creator claims** from an internal case study; no independent verification is present in the material. - The only externally checkable items are the event context (conference talk with applause) and PFF's public business description as stated by the speaker. # Delivery Observations: Mike Spitz, PFF — "Agents Don't Do Standups" ## Overall Tone - **Conversational and self-aware**, with light humor about his slot: "I'm in the slot before the snacks." - **Candid about caveats** — he preempts objections rather than overselling: "There's a big obvious caveat here, right? Smaller engineering teams are always going to be quicker than the big ones." - **Practitioner tone** rather than evangelist: he frames everything as "a case study we've been doing at PFF" rather than a universal prescription. ## Recurring Phrases & Verbal Habits - **"So" as a dominant discourse marker** — nearly every new point begins with it: "So, we have 100 million page views annually," "So, Scrum did not survive," "So, how do we start?" - **Repetition for emphasis mid-sentence**, possibly from live delivery: "we found that their — that their — that their output was 10x," "verifiable — verifiable — verifiable deterministic tasks," "What really matters is — really matters is — basically if the customers are happy." - **Recurring filler construction "go and [verb]"**: "how we can help engineers go and output more," "go and estimate the token expenditure," "go and coordinate all of those deploys." This appears dozens of times and is his most stable verbal tic. - **"Basically" as a frequent softener**: "you'd basically have huddles," "we basically blended the number of tickets with the code complexity," "it still feels like basically every other product from the company." - **"Kind of" and "cuz"** used casually throughout: "in the same kind of ethos," "cuz we're the bottleneck," "sprint planning we don't have… cuz we don't need to." ## Structural & Teaching Habits - **Numbers-first delivery**: leads with concrete metrics — "100 million page views," "9 million drafts," "25 times more deploys," "quality score was 8.6 out of 10." - **Do/Don't list structure** near the end: "You should start with boring repetitive tasks… Things you should not do is to try and onboard everyone at the exact same time." - **Signposting transitions explicitly**: "So, what did we have?", "So, how do we start?", "Where do you still use people?", "So, what things should you go and aim for?" - **Analogy-based explanation**: the car factory metaphor — "in a car factory, there's one thing which is building a door, another one fitting a steering wheel. The exact same thing happens for engineering." - **Rhetorical questions to the audience**: "What is the purpose of this meeting? What's the purpose of this process?" ## Audience Awareness - **Assumes shared engineering experience**: "I think all of us have probably felt that our feedback hasn't really been heard," "I think we've all experienced where it'll make a thousand lines of code." - **Acknowledges other talks**: "a bunch of people spoken about this today." - **Self-deprecating asides on slides**: "Got another slide which might look a little bit hectic, but just bear with me." ## Recurring Themes Framing - **Speed vs. caution tension** stated explicitly and repeatedly: "you should go slowly," but also "you don't want to be too shy… there's a lot of other companies that are going full speed." - **Customer satisfaction as the north star**, repeated: "It doesn't matter if the number of deployments are higher. What really matters is… if the customers are happy." - **Honesty about limitations**: "the bit we haven't gone and done at the moment," "Something we're not doing at the moment, but we will probably have to do once the subsidization of tokens ends." ## Uncertainty Notes - Repetitions and restarts in the transcript suggest **spontaneous, lightly-scripted delivery**, but without audio I cannot confirm pace, pauses, or audience reactions beyond one noted "Oops, sorry" (a slide or cue miscue). - The single "[applause]" at the end is the only audience signal available; mid-talk engagement cannot be assessed. # Observation Record: "Agents Don't Do Standups: Building the Post-Engineer Engineering Org" — Mike Spitz, PFF ## Speaker - All positions below are attributed to **Mike Spitz** (per title metadata), speaking about a case study at **PFF (Pro Football Focus)**, a sports data company. ## Context and Motivation - **Company profile:** PFF serves NFL/NCAA teams and has a consumer arm (fantasy football, sports betting); the NFL draft occurs end of month. - **Scale stats claimed:** ~100 million annual page views, ~9 million annual drafts, ~200 employees, ~20 engineers, fully distributed (India, Spain, US). - **Stated problem:** Falling behind competitors; consumer interest was in the draft tool while focus was on sports betting. - **Origin of experiment:** Spitz personally experimented with Claude Code ("Cloud Ops") starting November; this expanded to two engineers — described as their strongest frontend engineer and one of their strongest full-stack engineers. - **Framing question:** Shift from "how do we help engineers output more?" to **"how do we help make the agents quicker?"** - **Historical claim:** Engineering perks (Agile Manifesto, craftsmanship, foosball tables) existed because engineers were the bottleneck; that premise is now changing. ## Case Study Results (claimed) - **Deploys:** The 2-engineer team deployed ~5 times/day vs. a ~10-engineer team at ~1 deploy every 5 days — a claimed **25x difference**. - **Caveat stated by Spitz:** smaller teams are naturally faster, so part of the multiplier comes from team size; however, the small team still had to coordinate deploys with the larger team. - **Output validation:** PR count and code volume deemed unhelpful; they blended ticket count with code complexity and found **~10x output**. - **Delivery:** Features built in under two months vs. a prior estimate of four months; one engineer unblocked in under a month, creating a **compounding increase** in capacity. - **Customer satisfaction:** Statistically significant surveys averaged **8.6/10** quality, vs. ~7–7.5 pre-AI. Spitz emphasized customer happiness matters more than deploy counts. ## Process Changes ### What was eliminated ("Scrum did not survive") - **Project manager role** — "multiple games of telephone" removed. - **Sprint planning** — estimation "doesn't really make any difference." - **Daily standups** — tickets auto-update based on PR status. - **Sprint refinement** — absorbed into spec/LDD flow. - **Retrospectives** — replaced by customer satisfaction surveys, deployment metrics, and immediate issue flagging ("this one might be a little controversial," Spitz acknowledged). ### What replaced it - **Huddles:** every other day, 30–60 minutes, with engineers plus product and design; instant feedback; deploy MVPs to production quickly. - **Development flow:** agent interviews humans → spec feedback → agent-generated **LDD (lightweight design document)** via a skill that learns prior LDD patterns for consistency → distributed for engineer feedback → automatic ticket and PR creation. - Tickets are structured so none block each other; blocking dependencies are flagged. ### Qualification on estimation - Token-cost estimation will likely be needed once token subsidization ends. ## Implementation Guidance - **Start with engineers having the best systems knowledge** ("speak to them, they'll sort it out" people). - **Go slowly:** phased approach, not org-wide rollout. - **Experiment in non-critical systems first** — his November proofs of concept were low-traffic before moving to the 100M-pageview product. - **Honesty about fit:** "Not everyone can drive a sports car." Curious, self-directed engineers will thrive; engineers needing prescriptive specs will struggle. ## Engineering Practices - **Tasks must be verifiable and deterministic**, including product/org-specific ones (feature flags for trunk-based development, interactive element analytics). - **Agentic code review scope:** agents handle opinionated nitpicks (variable names, style) — removing the "emotional aspect" — while engineers focus on system design and big-picture review. - **Humans still involved** in security, product feel, and scale/complexity control via prescriptive LDDs (to counter over-engineering and "a thousand lines of code" outputs). - **Agents take shortcuts** — humans needed for security checks. - **Product feel warning:** tools built fast often feel "created by a cloud code"; engineering must preserve brand consistency. ## Factory Metaphor and Skills - Treat the development lifecycle as a **factory of composable elements** (branch naming, feature flags, API patterns abstracted into skills). - **Caution:** avoid consuming others' skills with strong software opinions conflicting with the org's own. ## Automation Pipeline - Fully autonomous from spec → LDD → tickets → PRs. - **QA:** merges auto-deploy to staging; a QA agent checks tickets against acceptance criteria; failures are flagged. - **Planned (not yet done):** agents that read failed acceptance criteria and auto-create fix PRs — enabling **self-healing** and parallel agent work, contingent on trusting agents. ## Recommendations ### Do - Start with boring, repetitive tasks engineers hate (maximizes buy-in). - Remove redundant process; question each meeting/process purpose. - Encode team culture and patterns (e.g., service-repository pattern for APIs) in skills. - Ensure guardrails work before autonomy. - Start with the best engineers. ### Don't - Onboard everyone simultaneously; hackathon-style rollouts fail because every org differs. - Be too conservative — competitors are moving fast; being months behind compounds ("few months behind now might be 12 months behind later"). Spitz admitted feeling behind personally. - **Structural advantage claim:** small companies (~20 engineers) can scale this far more easily than enterprises with 1,000–10,000 engineers. ## Closing - Spitz noted he described features without showing them; a QR code offered attendees access to try them. # Speaker Attribution Record ## Video **Title:** Agents Don't Do Standups: Building the Post-Engineer Engineering Org — Mike Spitz, PFF **Video ID:** `01a15ca9-4b20-7adc-b5e7-551139d54469` ## Speakers | Speaker | Role | Evidence | |---|---|---| | **Mike Spitz** (named in title) | **Primary/sole presenter** — represents himself as speaking for PFF (sports data company) about an internal case study (January–March) | Full transcript is a single continuous first-person talk; opens with "I'm in the slot before the snacks. I'm here to speak about..." | - **No other speakers** appear; no guests, narrators, or Q&A voices are present in the transcript. - Transcript ends with `[applause]`, indicating a live conference-style audience (non-speaking). ## Referenced Sources & Claims (as stated by the speaker) - **Internal PFF metrics** (speaker's own claims, not independently sourced): - 100 million annual page views; 9 million annual drafts - ~200 employees, ~20 engineers - Case study: 25x more deploys, ~10x output, quality score 8.6/10 from "statistically significant surveys" - **Named third-party concepts:** Agile Manifesto, software craftsmanship, Cloud Ops (speaker's experimentation starting point), Claude Code/"cloud code"/Codex (referenced as tools), trunk-based development, service repository pattern. - **Case study participants (non-speaking):** two PFF engineers — one strongest front-end, one strongest full-stack. ## Promotional Segments - **Closing promotion:** speaker invites audience to scan a QR code to try the product's features ("if anyone does want to have a play around, feel free to scan the the QR code"). This doubles as a product demo invitation for PFF's consumer tool. ## Availability & Uncertainty Notes - **No curated metadata supplied** — no channel info, comment availability, sponsor list, or publication date. - Speaker affiliation ("Mike Spitz, PFF") comes from the title only; the transcript itself does not state the speaker's name. - No external citations, URLs, or published sources referenced in the transcript. \>\> All right. So, I'm in the slot before the snacks. I'm here to speak about the host engineering org and a case study we've been doing at PFF started in January and we finished it in March. PFF is a sports data company. We help NFL and NCAA teams figure out what they should be doing and we also have a consistent We also have a consumer arm which does fantasy football, sport betting and for those of you who know American football there's a draft happening end of the month and so allows people to basically play as one of these teams. We're fully distributed engineering team. So, we got engineers in India, we got engineers in Spain and all the states in America. Um but first let's go into some kind of stats. So, we have 100 million page views annually. We have 9 million drafts happen on an annual basis. It's a fairly popular tool. And the issue that we had was we were 200 employees around 20 engineers and we were falling behind our competitors. We were focusing on sport betting stuff, but a lot of our consumers were actually interested in this and then with Cloud Ops coming out, I started experimenting around November on a personal level and then it got spun out to two engineers. One of them was our strongest front end engineer and the other one was one of our strongest full stack engineer. So, really the question is asking was instead of figuring out how we can help engineers go and output more, how do we help make the how do you help make how do you help make the agents quicker? Right. So, I think if we all think historically software engineering you got the Agile Manifesto, software craftsmanship. Um you've got a lot of good perks and benefits for engineers from foosball tables to sleeping pods to pretty much every perk that most other industries really don't have and it's cuz we're the bottleneck and if companies are able to go and optimize for that, it gives them a lot of benefit. But now things are changing. So, I just want to go straight into how the case study ended up. So, we had a 25 times more 25 times more of deploys. So, the two engineers were deploying five times five times every five were deploying five times every day and the other team was a team of around 10 engineers. They're doing it pretty much one deploy every five days. There's a big obvious caveat here, right? Smaller engineering teams are always going to be quicker than the big ones. So, there is an element of that multiplier that is just from it being a smaller engineering team. However, that smaller target team still had to coordinate all of those daily still had to go and coordinate all of those deploys with the bigger team. So, there was still that there was still that kind of issue that was happening. And this one this is always hard. How do you validate like the output is actually helpful? And the number of PRs isn't helpful. The amount of code isn't helpful. So, we basically blended the number of tickets with the code complexity and we found that their we found that their that their output was 10x. Got another slide which might look a little bit hectic, but just bear with me. Um So, these were the features that we went and constructed with those two engineers. It took them under two months. If you're going to do this before, we were estimating it's going to take four months. The big thing you can probably have a look in the in the top half is one of the engineers gets unblocked in under a month and then start building other stuff. Whereas in the old way, they're both blocked for three months and so you get this thing where you now have a compounding increase where it's not just faster for that stuff, but you're now able to do a lot more stuff than you were able to do before. And the one thing that I really want to go and basic basic go and highlight is doesn't matter if the output's more. It doesn't matter if the number of deployments are higher. What really matters is really matters is basically if our customers if the customers are happy. And so we did statistically we did statistically significant surveys and the average quality score was 8.6 out of 10. What's interesting was before AI we would probably average seven seven and a half. So, we weren't really delivering what the what the customers had been interested in. So, Scrum did not survive. We were we were basically having a look not just on an engineering front and all of the delivery gains from that, but also from a process standpoint. And so, no need for a project manager. We don't need to play multiple games of telephone and everything we're doing was optimizing to be as quick as possible. Engineers aren't the bottleneck. So, we don't need to have all the old ceremonies that we had before. So, what did we have? It looks pretty basic. We basically had a We basically had huddles. So, those huddles were basically every other day. They'd be like half an hour maybe an hour. You'd have the engineers, someone from product, someone from the design team and you would speak about the things you've been building the last a couple days. You get instant feedback. We would try to deploy to production as fast as possible in an MVP state and get as much feedback as possible also. And that development flow is we have a spec. I think most of us are probably fairly familiar around this, but we get the agent to go and interview us. We get feedback on that spec and then we make a lightweight design document. That's done by That's done by the agent. So, we have like a skill and the and the nice thing about that is it analyzes how we've done all the LDDs before and so anything that we're building is in the same kind of ethos as everything else that's been built. So, it's not a cloud code It's not like a cloud code specific kind of thing. And then those LDDs they get distributed and we get feedback from all of the the engineers. And then at that stage we automatically create all we automatically create all the tickets and then the PRs after that. So, sprint planning we don't have sprint planning anymore cuz we don't need to have an hour going and basically estimating tickets cuz those estimations don't really make any difference. Something we're not doing at the moment, but we will probably have to do once the once the subsidization of tokens ends is we'll probably have to go and estimate the token expenditure to go see if we want to actually spend this amount of money on it. The daily standups we don't have to do cuz all these tickets get auto updated. That is specific to the status of the PR. So, so with the PRs open it goes auto in progress. If it goes into review it updates it, it gets merged, it gets closed. These things were obviously manageable to do before, but it's all been made a little bit easier. Sprint refinement we don't need to do cuz that happens in the spec and the LDD flow and then when we automatically create all of the tickets, we structure it in a manner so that the tickets are made so none of them are blocking each other and if there are ones that are blocking each other, that information is flagged up and highlighted. And retrospective this one might be a little controversial, but we rely on the customer satisfaction, the customer survey. That's the main thing really and then you got the normal development metrics like the deployment frequency. We ask all of our engineers to really flag when there is an issue to flag it immediately and to instead of hanging on till the end of the sprint to go and go and flag that issue where sometimes I think all of us have probably felt that our our feedback hasn't really been heard cuz it's been a sprint before. Oops, sorry. So, how do we start? You got to pick the engineers which have the best system in the knowledge and I think every engineering team probably has one or multiple engineers where if anyone ever gets kind of stuck or hung up on anything they're like, you should speak to them. They'll be able to sort it out. The other one is you should you should go slowly. So, um there is an appetite to give everyone all the coding assistance and open it all up, but I think with this you want a slow phased approach. And then you should experiment in non-critical systems. So, that's what I did in the November in the in like the two months before the case study. I was making small proof of concept features going going and pushing it to production. Didn't really get much attraction. So, if there was a bug or a mistake it didn't really matter and then we moved it to the thing which gets 100 million page views after that. Um the big big thing here though is not everyone can drive a sports car. And that's all right. There's That's not a big issue, but I think I think everyone needs to be a little bit honest around the engineering org and engineering team. And this new era is going to be hard for a few engineers. And I think the the type of engineer will there really strive is one who is curious. It's the engineer who if they haven't figured it out, they're going to spend a little bit of time just figuring out how something's been built. They'll be able to still be able to they'll be able to smash this easily. The old style of engineering which needs something really uh prescriptive as a spec, I think they're going to struggle. So, in the engineering side of things, you need verifiable verifiable verifiable deterministic tasks. I think a bunch of people spoken about this today. So, it ranges from everything from all the different types of tasks. But, there's also things which are specific for your product or your org. So, for us, it's feature flag cuz we do a trunk-based development. Um or it could be generating the interactive elements. Um generating the analytics for the interactive elements. Um Next thing is the agentic code review. So, with us, we didn't really like relying on agents to do code reviews for system design and what engineers would usually do code reviews for. We use agents to do the code reviews that engineers hate getting any feedback from. So, that's like the variable names, this doesn't fit the style or like those kind of opinionated manners is much easier to offload. Uh and then you can remove that whole kind of emotional aspect out of it. And then you just allow the engineers to focus on the big picture. Um we still need people involved. But, it's really heavy on the spec, really heavy on the LDD, the lightweight design document where you figure out how we're going to build this. And the thing I haven't touched on at the moment is the product. We're in an era where everyone's able to create anything in an hour. But, a lot of these tools have the brand feel and the product feel of something that's been created by a cloud code. And so, if you really want to get the best out of it, you really need to make sure that the engineering team is spending time making sure it still feels like basically every other product from the company. So, how would I recommend attacking this? You should go see your engineering development life cycle like a like a kind of a like a kind of a factory. So, you should think you're in a factory. How do you break that up into the each small composable element? So, in a car factory, there's one thing which is building a building a building a a door, another one fitting a steering wheel. The exact same thing happens for engineering, right? So, you have the branch name, you've got uh creating feature flags with trunk-based development, you've got the if you build APIs with a specific software design a pattern, you should abstract that into a composable skill. The one thing I would flag is I'm not a big fan of um a consuming other people's skills if they have strong software kind of opinions that are in contrast to the today's engineering org cuz you're just going to kind of end up in issues. So, you just need to make sure that any skills that are getting composed are still kind of matching. Uh And yeah, this is just at the moment pretty much everything is fully autonomous from the spec, LDD, ticket from the PR. Uh we have a QA process also. So, what happens is um whenever we merge a PR, it automatically deploys onto staging. When the deployment on staging has happened, we will spin up a a QA agent which has a look at all of the tickets that have happened, has a look at the acceptance criteria, and it will go and then QA against that. And then if everything's a pass, I mean, great. And and then if everything hasn't, it will flag what those items are. And the bit we haven't gone and done at the moment, but I'm um I'm but I'm aiming in the next um a couple months is to then have an agent have a look at those tickets, find out where the acceptance criteria hasn't happened, and then automatically create the PRs. And so, then you get into this flow where agents can basically uh self-heal. And the cool thing about that is it lets us do multiple things in a parallel cuz we're now in a position where we basically trust agents as well. Uh where do you still use people? I mean, I've experienced this, but they do like to use they they do like to use they like to use shortcuts. Um So, got to make sure the the the security side of things is behaving. A product feel, I spoke about that a little bit earlier. And then the scale and engineering complexity for task, the LDD is really meant to help on this. So, I think we've all experienced where it'll make a thousand lines of code or over-engineer something. If you're really prescriptive on that engineering document at the start, you can really uh prevent that from happening. So, what things should you go and aim for? You should start with boring repetitive tasks, ideally things engineers hate cuz you're going to get the most amount of buy-in from that. Remove as much redundant process as possible. And I know it can be strange when you've been doing something for like a two decades plus to just uh chuck it all out, but I would ask you, what is the purpose of this meeting? What's the purpose of this a process? Is it just cuz everyone else has been going and doing it before, or is it cuz it actually helps out? Uh make sure your team's a personal kind of engineering culture and the patterns are encoded in skills. So, if there are software design patterns that you really do, so for us, whenever we build an API, we focus on the service repository pattern. Uh make sure your guardrails are fully functional before you get into before you get into an autonomous flow. And you should start out with the best engineers. Things you should not do is to try and onboard everyone at the exact same at time. Uh I think a big reason why a lot of these things haven't really panned out is cuz we've given everyone a cloud code codex and given them a hackathon and like, "Sweet, we've done everything. They should now be able to sort it all out." It's just not that easy. Every engineering org is completely different uh and every engineering org's style is really different. And you just need to go and have a slow-phased approach to make sure uh that that transition is happening smoothly. And that's why I think those small companies are at a huge advantage of the big enterprise companies cuz it's really easy for me to scale this out when I've got 20 engineers. It's really hard for me to scale this out if I was in charge of 100 or if I was in charge of 1,000 engineers or if I was in charge of 10,000 engineers. So, um but you don't want to be too shy. You don't want to be too You don't want to be too conservative because the fact is that there's a lot of other companies that are going full speed. And um Um for us, even from our perspective, I felt a few months behind and I was kind of feeling it. And I think if you think about the compounding impact that I was talking about at the start, that's just going to carry on happening. So, like a few months behind at the moment might be six months behind in a few months, might be 12 months behind uh a little bit afterwards. And then again, just just the just uh take it slow. Uh needs a phased needs a phased kind of approach and rely on your engineers to let you know whether you can scale things faster or if it needs a bit more time. I know I spoke to you about a lot of features that we built, but I didn't show you any of the features. Uh if anyone does want to have a play around, feel free to scan the the QR code and then you can have a look at all the stuff. Uh cool. Thank you, everyone. \>\> \[applause\]