Cristian Pogan

What this looks like in practice

Fifteen technical insights, each unlocking a business metric - what usually happens, why it keeps happening, and the system to run instead.

15 insights · Hiring to founder brain · Updated as discovered

Which insights can we apply in your current work?

Your first technical hire spends month one doing archaeology

Scroll →

Your first technical hire spends month one doing archaeology Five stages: Interview (5 weeks of questions); Real Process (not the official one); Shadow System (one shared password); Write It Down (billed at day rate); Build (week six). A terminal shows the configuration: board: operations; license_cost: 0; seats: unlimited. Annotation: 25 days at 180 EUR, before a line of code. A feedback loop returns to an earlier stage: do this before they arrive. INTERVIEW 5 weeks of questions REAL PROCESS not the official one SHADOW SYSTEM one shared password WRITE IT DOWN billed at day rate BUILD week six do this before they arrive Plane.so, self hosted on your VPS board: operations license_cost: 0 seats: unlimited 25 days at 180 EUR, before a line of code 01

✕ Usually

You hire a developer to build something and they spend the first five to six weeks interviewing your staff about how the work is actually done today.

? Why

Nobody wrote the real process down, only the official one. The real version lives in three people's habits and one spreadsheet with a shared password.

→ Instead

Capture the process yourself before anyone technical arrives, in a self hosted Plane.so board that costs you a VPS instead of a per seat licence. Rough notes are fine. That documentation costs around 180 EUR per day at developer rates otherwise, and typically 20 to 25 days of it.

✓ Relevant if

You are about to bring in your first developer or agency.

Delegate the work, never the definition of correct

Scroll →

Delegate the work, never the definition of correct Five stages: Acceptance Rule (you own this); Build (vendor owns this); Run (automatic); Exception (system cannot decide); Owner (named human). A terminal shows the configuration: correct = invoice_total equals delivery_note_total; owner: founder; exceptions_to: chatwoot. Annotation: one sentence, written by you, before anyone builds. A feedback loop returns to an earlier stage: rule gets sharper. ACCEPTANCE RULE you own this BUILD vendor owns this RUN automatic EXCEPTION system cannot decide OWNER named human rule gets sharper Plane.so ticket correct = invoice_total equals delivery_note_total owner: founder exceptions_to: chatwoot one sentence, written by you, before anyone builds 02

✕ Usually

The whole process goes to a vendor, including the decision about what counts as a good result.

? Why

Whoever defines correct controls the system. If that is the person building it, every later disagreement becomes a paid change request, typically 3 to 5 of them per project at 1,200 EUR each.

→ Instead

Write your acceptance rule in one sentence before work starts, and put it on the ticket in Plane.so. Route anything the system cannot decide into a Chatwoot queue that a named person owns, so exceptions land with you and not with the builder.

✓ Relevant if

You are outsourcing any operational process.

The steps people argue about are undecided, not hard

Scroll →

The steps people argue about are undecided, not hard Five stages: Map (every step); Sort (agreed vs disputed); Ship (80 percent, week one); Escalate (not a backlog item); Decide (one owner, one date). A terminal shows the configuration: type: decision; owner: operations_director; due: friday; blocked_steps: 3. Annotation: 4 to 7 weeks lost waiting for a meeting. A feedback loop returns to an earlier stage: unblocked, resume. MAP every step SORT agreed vs disputed SHIP 80 percent, week one ESCALATE not a backlog item DECIDE one owner, one date unblocked, resume Plane.so type: decision owner: operations_director due: friday blocked_steps: 3 4 to 7 weeks lost waiting for a meeting 03

✕ Usually

Automation stalls on one part of the process while the easy 80 percent finished in the first week.

? Why

When two people describe the same step differently there is no rule to encode. That is a management decision wearing a technical costume, and it delays projects by 4 to 7 weeks on average.

→ Instead

Ship every uncontested step now. Move the contested one out of the backlog and into a decision item in Plane.so with one named owner and a date, not a discussion thread.

✓ Relevant if

A project has been nearly finished for more than a month.

Ship one process end to end, and keep the manual path alive

Scroll →

Ship one process end to end, and keep the manual path alive Five stages: Pick One (not five in parallel); End To End (exceptions included); Dual Run (30 days); Measure (week three is the real test); Retire (named owner decides). A terminal shows the configuration: workflow: invoice_intake; retries: 3; on_failure: notify_human; dual_run_until: day_30. Annotation: week three is when the real cases arrive. A feedback loop returns to an earlier stage: next process. PICK ONE not five in parallel END TO END exceptions included DUAL RUN 30 days MEASURE week three is the real test RETIRE named owner decides next process Hatchet, running on your VPS workflow: invoice_intake retries: 3 on_failure: notify_human dual_run_until: day_30 week three is when the real cases arrive 04

✕ Usually

Five processes get automated in parallel so every department feels included, and the old way is switched off on go live day.

? Why

A half automated process is worse than a manual one, because staff now do the work and supervise a system. Real failure modes appear in week three under real volume, on the cases nobody described.

→ Instead

Sequence releases so each batch takes one process fully end to end, exceptions included, orchestrated in Hatchet so retries and failures are visible rather than silent. Keep the manual path for one full business cycle, roughly 30 days, with one person owning the decision to retire it.

✓ Relevant if

You have a go live date and no fallback plan.

Systems do not break, your business moves and nobody tells them

Scroll →

Systems do not break, your business moves and nobody tells them Five stages: Live (month one, 6 pct exceptions); Change (new supplier, new form); Drift (still green, still wrong); Exception Rate (20 percent is the alarm); Recalibrate (month 3 and month 6). A terminal shows the configuration: cron: quarterly; metric: human_touch_rate; alert_above: 0.20. Annotation: green dashboard, wrong answers. A feedback loop returns to an earlier stage: recalibrated, back to live. LIVE month one, 6 pct exceptions CHANGE new supplier, new form DRIFT still green, still wrong EXCEPTION RATE 20 percent is the alarm RECALIBRATE month 3 and month 6 recalibrated, back to live Hatchet scheduled review cron: quarterly metric: human_touch_rate alert_above: 0.20 green dashboard, wrong answers 05

✕ Usually

Something works beautifully for four months, then quietly produces wrong output that nobody notices for another three weeks.

? Why

You added a product line, changed a supplier or altered a form. The system is still perfectly correct about a business that no longer exists. Uptime dashboards stay green throughout, because the system responded, it just responded wrongly.

→ Instead

Track the share of cases a human had to touch, weekly, from your Chatwoot exception queue. Baseline is usually 5 to 8 percent. When it crosses 20 percent you have quietly reacquired a manual process. Book recalibration reviews at month 3 and month 6 as scheduled Hatchet jobs, so they happen without anyone remembering.

✓ Relevant if

You have automations running that you have not looked at this quarter.

AI prototypes model the finished screen, not the operation around it

Scroll →

AI prototypes model the finished screen, not the operation around it Five stages: Prototype (two days); Looks Done (the demo works); Missing (access, errors, corrections); Operations (credentials, retries, owners); Live (four months later). A terminal shows the configuration: secrets: infisical; retries: hatchet; owner: plane; rollback: manual_path. Annotation: keep it as the spec, not the foundation. A feedback loop returns to an earlier stage: next feature. PROTOTYPE two days LOOKS DONE the demo works MISSING access, errors, corrections OPERATIONS credentials, retries, owners LIVE four months later next feature what the prototype never asked secrets: infisical retries: hatchet owner: plane rollback: manual_path keep it as the spec, not the foundation 06

✕ Usually

A convincing working prototype appears from Lovable or Claude in two days, and the real build still takes four months from there.

? Why

Those tools are optimised to produce the end product. They do not ask who fixes wrong data, who has access to what, what happens when someone leaves, or how last month gets corrected. That is roughly 70 percent of the actual work.

→ Instead

Use the prototype to settle arguments with your team about what it should do, then treat it as a specification rather than a foundation. The operational layer is separate: Infisical for credentials so no password lives in a developer's file, Hatchet for anything that must retry or run in a sequence, Plane.so for who owns what.

✓ Relevant if

Someone showed you a working demo and you are deciding what to do with it.

Automation that needs your laptop open is not automation

Scroll →

Automation that needs your laptop open is not automation Five stages: Offline (you are asleep); Vps (24/7, 168 hours a week); Sessions (running on their own); Queued (ready by morning); Review (you decide, not you run). A terminal shows the configuration: schedule: nightly; session: persistent; secrets: infisical; orchestrator: hatchet. Annotation: 108 of 168 hours were being wasted. A feedback loop returns to an earlier stage: next night's work. OFFLINE you are asleep VPS 24/7, 168 hours a week SESSIONS running on their own QUEUED ready by morning REVIEW you decide, not you run next night's work Claude Code, unattended on VPS schedule: nightly session: persistent secrets: infisical orchestrator: hatchet 108 of 168 hours were being wasted 07

✕ Usually

The workflow only runs when you are at your desk, so it stops on weekends, during travel, and across the 8 hour gap between Brussels and New York.

? Why

Most tools are built to sit beside a person. Anything that depends on a session you personally started stops the moment you close the lid, and you lose roughly 60 percent of the available running hours in a week.

→ Instead

Move the work to a VPS that runs 24/7, orchestrated by Hatchet, with credentials held in Infisical rather than on the machine. Claude Code sessions run there on their own schedule, so work continues overnight and is finished when you open your laptop rather than starting then.

✓ Relevant if

Your systems only work during your working hours.

Automate the calendar, not the voice

Scroll →

Automate the calendar, not the voice Five stages: Angle (human, 1 hour weekly); Repurpose (18 assets); Schedule (automatic); Distribute (four channels); Measure (which angle worked). A terminal shows the configuration: input: one_angle; outputs: 18; channels: 4; human_step: angle_only. Annotation: automate the distribution, never the point of view. A feedback loop returns to an earlier stage: next week's angle. ANGLE human, 1 hour weekly REPURPOSE 18 assets SCHEDULE automatic DISTRIBUTE four channels MEASURE which angle worked next week's angle Claude Code session, VPS, weekly input: one_angle outputs: 18 channels: 4 human_step: angle_only automate the distribution, never the point of view 08

✕ Usually

A tool is bought to write and post automatically, output quality falls, and the whole thing is abandoned inside two months.

? Why

The bottleneck was never posting, it was deciding what to say. Automating the wrong half produces volume nobody engages with, and engagement typically drops 40 to 60 percent within six weeks.

→ Instead

Keep one human decision a week on the angle, then let unattended Claude Code sessions on the VPS handle repurposing into 15 to 20 assets, scheduling and distribution across channels. One hour of your time feeds a month of output.

✓ Relevant if

Your marketing output depends on you personally finding time.

Your network is a database you have never queried

Scroll →

Your network is a database you have never queried Five stages: Network (2,500 connections); Extract (Unipile); Structure (role, size, history); Filter (52 qualified); Engage (background routine). A terminal shows the configuration: source: sales_navigator; mode: continuous; writes_to: lead_database; unattended: true. Annotation: a second machine doing this all day, not you. A feedback loop returns to an earlier stage: replies enrich the record. NETWORK 2,500 connections EXTRACT Unipile STRUCTURE role, size, history FILTER 52 qualified ENGAGE background routine replies enrich the record Claude Code, dedicated laptop source: sales_navigator mode: continuous writes_to: lead_database unattended: true a second machine doing this all day, not you 09

✕ Usually

LinkedIn is scrolled reactively. There is no record of who you know, what they do now, or who they could introduce you to.

? Why

The value is in the structure, not the activity. A founder with 2,500 connections usually has 40 to 60 genuinely qualified opportunities sitting in it, and no way to see them.

→ Instead

Pull the whole network into a structured, filterable database through Unipile, so profiles, roles, company size and history become searchable fields. Run Sales Navigator discovery from a dedicated laptop with a Claude Code session working through it continuously, populating the same database while you do other things. Engagement then runs as a background routine, not a daily habit.

✓ Relevant if

Your best clients historically came from people you already knew.

You do not need Clay pricing to build a qualified list

Scroll →

You do not need Clay pricing to build a qualified list Five stages: Input (1,000 companies); Cascade (four providers in order); Escalate (only on a miss); Stop On Hit (no double paying); Verified (under 3 percent bounce). A terminal shows the configuration: order: icypeas, lusha, ai_ark, apollo; stop_on_hit: true; coverage: 0.88; cost_per_record: 0.28. Annotation: each record only costs what it took to find. A feedback loop returns to an earlier stage: next batch. INPUT 1,000 companies CASCADE four providers in order ESCALATE only on a miss STOP ON HIT no double paying VERIFIED under 3 percent bounce next batch enrichment cascade order: icypeas, lusha, ai_ark, apollo stop_on_hit: true coverage: 0.88 cost_per_record: 0.28 each record only costs what it took to find 10

✕ Usually

Lead data is bought from one expensive platform at 800 to 1,500 EUR a month, or from a cheap provider where 30 to 40 percent of contacts bounce.

? Why

No single provider has everyone. Paying one vendor for full coverage means paying for the misses as well as the hits, on every single record.

→ Instead

Run a cascade that stops as soon as it finds a match. IcyPeas first, then Lusha, then AI Ark, then Apollo, so each record costs only what it took to find. Typical outcome is 85 to 90 percent coverage at 20 to 25 percent of single vendor cost, with bounce rates under 3 percent.

✓ Relevant if

You are paying for lead data and still cleaning the list by hand.

Proof that you did the work is worth as much as the work

Scroll →

Proof that you did the work is worth as much as the work Five stages: Search (industry and client terms); Cascade (SerpAPI, Brave, DuckDuckGo); Match (relevant only); Clip (Firecrawl archive); Record (dated, permanent). A terminal shows the configuration: providers: serpapi, brave, duckduckgo; clipper: firecrawl; dedupe: true; archive: permanent. Annotation: 10 hours a month becomes 30 minutes. A feedback loop returns to an earlier stage: runs every hour. SEARCH industry and client terms CASCADE SerpAPI, Brave, DuckDuckGo MATCH relevant only CLIP Firecrawl archive RECORD dated, permanent runs every hour clipping pipeline, VPS, hourly providers: serpapi, brave, duckduckgo clipper: firecrawl dedupe: true archive: permanent 10 hours a month becomes 30 minutes 11

✕ Usually

An agency delivers real results and still loses the client, because coverage and mentions were reported in a monthly summary nobody trusted.

? Why

Clients cannot see effort, only artefacts. Manual monitoring and clipping takes 6 to 10 hours a month per client and is the first thing dropped when the team is busy.

→ Instead

Run a search cascade across SerpAPI, Brave and DuckDuckGo so coverage is found even when one index misses it, then clip and archive each article with Firecrawl into a dated, permanent client record. Monitoring drops to under 30 minutes a month and the evidence assembles itself.

✓ Relevant if

You sell a service whose value is hard to show at renewal.

Consulting grade documents are a formatting problem, not a thinking problem

Scroll →

Consulting grade documents are a formatting problem, not a thinking problem Five stages: Raw (your actual analysis); Structure (one argument per page); Layout (consistent, automatic); Review (you check the logic only); Deliver (4 hours total). A terminal shows the configuration: input: raw_notes.md; output: 18_slides; human_step: argument_only; time: 4h. Annotation: the thinking was already done, only the packaging was slow. A feedback loop returns to an earlier stage: next deck reuses the structure. RAW your actual analysis STRUCTURE one argument per page LAYOUT consistent, automatic REVIEW you check the logic only DELIVER 4 hours total next deck reuses the structure Manus input: raw_notes.md output: 18_slides human_step: argument_only time: 4h the thinking was already done, only the packaging was slow 12

✕ Usually

A partner quality deck takes 5 to 8 working days, or is outsourced at a rate that only makes sense on your largest deals.

? Why

The analysis in your head is usually already good enough. What is expensive is structure, visual consistency, and the discipline of one argument per page.

→ Instead

Take your raw thinking into Manus and let it carry the structure and the layout, then spend your own time only on the argument. Typical result is 6 days down to 4 hours, at consulting firm visual quality.

✓ Relevant if

You lose deals to firms with better looking documents than answers.

Outbound email machinery works better on suppliers than on prospects

Scroll →

Outbound email machinery works better on suppliers than on prospects Five stages: Suppliers (142 open items); Sequence (day 0, 3, 7); Follow Up (automatic, no reminders); Reply (58 percent respond); One Inbox (Chatwoot, shared). A terminal shows the configuration: audience: suppliers; steps: 3; reply_routing: chatwoot; owner: operations. Annotation: same tool, completely different reply rate. A feedback loop returns to an earlier stage: closed items drop off. SUPPLIERS 142 open items SEQUENCE day 0, 3, 7 FOLLOW UP automatic, no reminders REPLY 58 percent respond ONE INBOX Chatwoot, shared closed items drop off Instantly.io to Chatwoot audience: suppliers steps: 3 reply_routing: chatwoot owner: operations same tool, completely different reply rate 13

✕ Usually

A cold email platform is bought for new business, produces a 1 to 2 percent reply rate, and quietly goes unused.

? Why

Cold outreach fights for attention. The same machinery pointed at people who already know you and owe you something works immediately, because you have a legitimate reason to follow up.

→ Instead

Point Instantly.io at supplier chasing, renewals and document collection, where reply rates run 45 to 70 percent, then land every response in a single Chatwoot inbox so nothing sits in one person's mailbox. Chasing that consumed a full day a week drops to under an hour.

✓ Relevant if

Chasing suppliers for documents eats someone's week.

Stop chasing perfect document reading and design the exception lane

Scroll →

Stop chasing perfect document reading and design the exception lane Five stages: Receive (1,000 documents a month); Read (OCR extraction); Confidence (threshold 0.95); Clean (904 documents, 18s each); Exception (96 documents, one owner). A terminal shows the configuration: ocr_confidence_min: 0.95; auto_path: 0.904; exception_queue: chatwoot; measure: queue_length. Annotation: the last 10 percent costs more than the first 90. A feedback loop returns to an earlier stage: corrections teach the next batch. RECEIVE 1,000 documents a month READ OCR extraction CONFIDENCE threshold 0.95 CLEAN 904 documents, 18s each EXCEPTION 96 documents, one owner corrections teach the next batch document pipeline ocr_confidence_min: 0.95 auto_path: 0.904 exception_queue: chatwoot measure: queue_length the last 10 percent costs more than the first 90 14

✕ Usually

Invoice or delivery note automation is judged on whether it reads everything correctly, and rejected the moment it does not.

? Why

A real share of documents are photographed at an angle, handwritten, or come from a supplier whose layout nobody has seen. No system reads all of them, and the last 10 percent costs more than the first 90.

→ Instead

Automate the clean majority, around 88 to 92 percent, and route anything uncertain into a Chatwoot review queue owned by one named person, with the document and the extracted fields side by side. Measure the queue length, not the accuracy percentage. Processing time per document goes from about 4 minutes to under 20 seconds on the clean path.

✓ Relevant if

You process supplier documents in volume and have already written off automation as unreliable.

A general AI assistant forgets your business every morning

Scroll →

A general AI assistant forgets your business every morning Five stages: Capture (meetings and decisions); Context (your business, not the internet); Ask (no re-explaining); Research (SerpAPI, Brave, DuckDuckGo); Answer (grounded in your record). A terminal shows the configuration: context: your_meetings; research: cascade; schedule: continuous; model: replaceable. Annotation: the context is the advantage, not the model. A feedback loop returns to an earlier stage: every answer becomes context. CAPTURE meetings and decisions CONTEXT your business, not the internet ASK no re-explaining RESEARCH SerpAPI, Brave, DuckDuckGo ANSWER grounded in your record every answer becomes context Hermes, unattended on VPS context: your_meetings research: cascade schedule: continuous model: replaceable the context is the advantage, not the model 15

✕ Usually

You re-explain the same context at the start of every conversation, and the quality of the answer depends on how much you remembered to paste in.

? Why

Chat tools are stateless by design. A system that already holds your meetings, decisions and commitments outperforms a smarter model with no memory of you, because roughly 80 percent of a good answer is context rather than reasoning.

→ Instead

Build the context layer once. A Hermes style agent holds your meeting transcripts, decisions and open commitments, runs research through the SerpAPI, Brave and DuckDuckGo cascade on its own schedule on the VPS, and returns answers grounded in your actual business. Prep that took 45 minutes of re-explaining becomes a question.

✓ Relevant if

You use AI daily and still feel you are doing most of the work.

Recognise your own situation in one of these?

Thirty minutes, no charge. Tell me what you have built and where it stopped.

Book a 30-minute call