# Technical Operations Field Guide — Technical VA — iHouseDesign 2026 **Published:** June 2026 · **Slug:** mujtaba-technical-va-field-guide-v1 --- ## Why This Exists iHouseDesign technical work has repeatedly become founder-dependent because issues are not always diagnosed, documented, owned, verified, and closed visibly. A virus infection was present on a major hosting account for months before anyone noticed. SSL certificates were installed without written confirmation. Client emails were sent from the tech address without identifying the sender. Security keys were never recorded in a shared location. This guide exists to make expectations explicit so that technical operations does not depend on Arseni noticing every problem. ## The Role In Plain Language A Technical VA at iHouseDesign is not "answer tickets" or "wait for instructions." The database shows hundreds of directed asks that did not get closed without follow-up. The role is to take ownership before being asked again. Success means: Success means: - **Verify access**: before assuming it works — test login, test workflow, leave proof. - **Reproduce issues**: before describing them. A client saying "the site is broken" is not a diagnosis. - **Diagnose before escalating**: — SSL confirmation notices are not emergencies. Registrar upsells do not need Arseni to decide. - **Document exact steps**: so the same issue is solved once, not every six months. - **Protect client sites**: by scanning proactively, not reactively. - **Coordinate**: with Hendra, Mohammad, Mira, and Arseni — but own your lane before handing off. - **Close loops visibly**: — a fix that nobody can see in the record did not happen. - **Prevent founder emergencies**: — a problem caught early is a routine task. A problem caught late is a crisis. ## 30 · 60 · 90 Day Progression ### First 30 Days Prove access works. Show ability to reproduce and document issues. Close small technical loops with proof — screenshots, URLs, before/after. Ask better questions with evidence attached. Search existing SOPs before asking Arseni. Confirm credential security practice — locate the SI2 bot, confirm you can retrieve credentials from it, and confirm you do not have plaintext passwords stored anywhere that could be pasted into a group channel. The rule is not "try to remember not to paste passwords." The rule is structural: SI2 is the only source, so there is nothing to paste. ### First 60 Days Own recurring technical routines: SSL renewal checks, hosting space monitoring, backup verification, tech@ email triage. Reduce repeated access/DNS/SSL/backup confusion. Maintain visible status in shared systems. Escalate only after diagnosis. ### First 90 Days Turn repeated technical exceptions into reusable checklists, decision trees, and SOPs. Make technical support less dependent on Arseni's memory. Improve speed and reliability of client technical work. Build automated monitoring routines where possible. ## 14 Principles Mapped To iHD Reality ### 01. Diagnosis before escalation > "I trust Mujtaba with simple things — register accounts, figure out how Zoom works, talk to tech support of Zoom or other apps." > — Arseni Ria / IHD onboarding thread / 2026-05-29 **What This Means At iHouseDesign:** Trust is earned by diagnosing before escalating. When a domain registrar sends an upsell offer, the Technical VA should recognize it as upsell and advise the client — not forward it to Arseni. When an SSL renewal notice arrives, the response should be "here is what this means, here is what I did, here is when it renews next." **Real Situation From The Database:** Mujtaba correctly handled a domain renewal email for Maquette: "Suggested: No need to buy the additional domains. Because this is a common upsell tactic from domain registrars." That is the correct pattern — recognize, diagnose, advise, close. The same pattern should apply to SSL notices, hosting alerts, and client technical questions. **What You Should Do Differently:** Before any escalation to Arseni, write one sentence explaining what you already checked and what you concluded. If the answer is clear, act on it and post the result. Escalation is for exceptions you cannot resolve — not for confirmation of obvious patterns. ### 02. Evidence and closure > "Done means proof in the record. Not 'I handled it.' Not 'all good.' Not silence." > — Arseni Ria / Operational standard / 2026-05-29 **What This Means At iHouseDesign:** The database shows 189 open loops mentioning one Technical VA — directed asks that did not receive a visible close. "Done" is not a private DM. "Done" is a message in the shared thread with a screenshot, a URL, a before/after, or a clear "this is what happened, here is the proof." **Real Situation From The Database:** After the Bluehost 2 virus cleanup, the work was done but Arseni could not confirm whether all clients were notified: "I can bet Mujtaba did not email ALL the clients saying services are restored. I could check — it would take 10 minutes." The work was real. The visibility was missing. **What You Should Do Differently:** After closing a technical issue, post: (1) what the problem was, (2) what you did, (3) verification proof — screenshot, link, or test result, (4) any remaining risk. Make it impossible for Arseni to wonder whether the work was completed. ### 03. Access verification > "Your job in onboarding is the setup steps. Tia's job is to confirm everything works." > — Arseni Ria / IHD onboarding thread / 2026-06-02 **What This Means At iHouseDesign:** Giving someone access is not the same as onboarding them. Setup without verification is incomplete. When a new team member had to ask for WhatsApp group access 90 minutes after requesting it, that is a gap between "access exists" and "access works." The same applies to hosting accounts, email, Asana, Dropbox, and every technical system. **Real Situation From The Database:** Arseni asked directly: "was Tia not given access to this during onboarding? Accounting Email, Billing Email, Technical Support Email." The access existed in theory but was not confirmed in practice. **What You Should Do Differently:** When you set up access for someone: (1) confirm they received the invitation, (2) ask them to test the login while you watch, (3) verify one real workflow end-to-end, (4) post confirmation in the shared thread. Access is not done until the other person has used it successfully. ### 04. Technical ownership > "Everything needs a DRI." > — Dan Martell / Stop Working Hard — 12 Laws of Business **What This Means At iHouseDesign:** The tech email routing system assigns `solo_technical` mode to the Technical VA as primary — the only person in that mode. That means you are the DRI for first-line technical support. When an SSL notice comes in, you own it until it is resolved or escalated with evidence. When a hosting space alert fires, you own the response. No task is "everyone's background anxiety." **Real Situation From The Database:** The `tech_email_assignment_audit` table shows entries with `solo_technical` mode: primary = Mujtaba Azaidi. The reason: "Simple technical request routed to one execution owner only. Escalate to a client manager only if blocked, estimate needed, or no update by SLA." This is the formal DRI designation. **What You Should Do Differently:** Treat every tech@ email that lands in your inbox as yours until you explicitly hand it off. Log what you did, when you did it, and what the next action is. If you need to escalate, attach your diagnosis first. ### 05. Shared records > "If you're not going into Telegram, Trackabi, or Teams, not flagging inconsistencies, then you're not doing the REAL job." > — Arseni Ria / Recurring invoicing / 2025-10-19 **What This Means At iHouseDesign:** Private fixes must return to the shared record. When Mujtaba answered the SSL confirmation for Cosimo Pizzulli — that was correct. The response was in the tech@ thread, visible, documented. But when work happens only in DMs or disappears into private channels, the organization cannot reconstruct what happened. **Real Situation From The Database:** Mujtaba shared SOP_OPSOFFBOARD-001, SOP_FINHOSTING-001, SOP_OPSASANA-001, SOP_OPSESCAL-001, and SOP_FININV-003 in the onboarding thread — an excellent example of bringing knowledge to the shared record. But security keys for Amazon S3 were never recorded anywhere: "No i have never record the key for Amazon s3 ever." That is a shared-record failure. **What You Should Do Differently:** When you discover a gap in shared records — security keys, access credentials, SOP steps, client contact details — create the record immediately. Do not wait for someone to ask. Make the shared record more complete than when you found it. ### 06. Verification discipline > "The scan report is generated on the server. We scanned it ourselves using FTP/SSH access." > — Mohammed Mosaad / Bluehost 2 emergencies / 2026-06-04 **What This Means At iHouseDesign:** Screenshots, exact URLs, and logs matter. "I checked" is not evidence. "I checked the SSL certificate at https://pizzulli.com — it expires December 10, 2026, Pair Networks auto-renews" is evidence. The difference between these two statements is the difference between guessing and knowing. **Real Situation From The Database:** During the Bluehost 2 virus incident, Mujtaba reported: "Yes, we cleaned the sites, we added the recaptcha to affected contact forms." But the specific virus types (SL-PHP-BACKDOOR-GENERIC, SL-PHP-FILEHACKER) were only visible in the security scan logs — not in the status update. Adding the log details would make the closure verifiable. **What You Should Do Differently:** Every status update should include: the exact URL or system checked, what tool was used, what the result was, and a screenshot or log reference. A quick phone photo of the screen counts. A pasted terminal output counts. "Looks fine" does not count. ### 07. Rollback planning > "We previously scanned it ourselves using FTP/SSH access, and we also used Bluehost support to run their scan." > — Mohammed Mosaad / Bluehost 2 emergencies / 2026-06-04 **What This Means At iHouseDesign:** Before making any change to a live client site — WordPress update, plugin change, DNS record edit, SSL reissue — know how to undo it. Rollback is not an afterthought; it is a prerequisite. If you do not know how to revert, you are not ready to change. **Real Situation From The Database:** Hendra suggested: "that's why I suggest you for our own dedicated server for our clients so we can set auto virus monitoring cpanel server system." The recurring pattern is that shared hosting (Bluehost) limits what can be monitored. When working within those limits, you need to know the restore path — backup location, restore procedure, estimated downtime — before touching anything. **What You Should Do Differently:** Before every maintenance or change operation on a client system, write down: (1) current state, (2) change to make, (3) how to revert, (4) backup location. Post this before making the change. If the change breaks something, you have the rollback plan ready in the same thread. ### 08. Network verification > "No major actions needed here. This is a confirmation notice, not a request. Site is secure under HTTPS. Certificate is valid from May 25 to Dec 10." > — Mujtaba Zaidi / SSL response to client Cosimo Pizzulli / 2026-05-28 **What This Means At iHouseDesign:** DNS, SSL, and email changes require verification before and after. When Mujtaba correctly explained the SSL certificate status to a client, he demonstrated the correct pattern: check the current state, interpret what it means, communicate clearly, note the next renewal date. **Real Situation From The Database:** Mujtaba's SSL response to Cosimo Pizzulli is a model technical communication: it identifies the certificate type, validity period, auto-renewal behavior, and explicitly tells the client no action is needed. The same thoroughness should apply to every DNS propagation check, email authentication verification (SPF/DKIM/DMARC), and hosting migration test. **What You Should Do Differently:** Use this exact standard for all DNS/SSL/email work: verify before the change, document the change, verify after the change, communicate the result. The monitor_ssl_log is empty (0 rows) — start logging SSL check results so the organization has a history of what was verified and when. ### 09. Backup integrity > "Hosting/CMS Subscriptions Protocol + Unified Offboarding Protocol." > — Mujtaba Zaidi / SOP_OPSOFFBOARD-001 / 2026-05-28 **What This Means At iHouseDesign:** Backups are only real if the restore path is known. Maintaining SOPs is good. Testing whether the backup actually restores is better. Creating SOPs for hosting/CMS subscriptions and offboarding protocols is the ownership pattern that should apply to backup verification too. **Real Situation From The Database:** Mujtaba shared SOP_OPSOFFBOARD-001 and SOP_FINHOSTING-001 in the onboarding thread, directing Tia to NotebookLM for questions. The SOPs exist. The question is whether they include explicit backup verification steps — and whether you have actually tested a restore from each backup location. **What You Should Do Differently:** Quarterly: pick one client site, download the latest backup, restore it to a staging environment, confirm it works, document the result. The goal is not paranoia — it is knowing that the backup system actually functions before an emergency proves otherwise. ### 10. Emergency severity > "Bluehost 2 account had these viruses for months. Nobody checked. Nobody saw it for months or years, even though we paid system administrators and technical people." > — Arseni Ria / Tia Lodewyk thread / 2026-05-29 **What This Means At iHouseDesign:** Technical emergencies need severity levels. Not every alert is a crisis. An SSL renewal notice is informational. A site infected with backdoors is a P1. A hosting disk at 95% is a P2. You need to classify and communicate severity so the right people respond at the right speed. **Real Situation From The Database:** The Bluehost 2 malware was only discovered reactively — the security log shows 100+ malware files detected on 2026-05-08, but infections were present for months. Mujtaba noted "next step is to check Bluehost 1 and Hostinger" — that proactive expansion is the right pattern. **What You Should Do Differently:** When you discover a problem, assign a severity level in the first message: P1 (site down, security breach, data loss), P2 (degraded, non-critical error), P3 (routine maintenance, renewal notice). This tells everyone whether to drop what they are doing or handle it during normal hours. ### 11. AI as assistant > "Knowledge is not the bottleneck. Desire is. Desire to search. Desire to act." > — Arseni Ria / IHD onboarding thread / 2026-05-28 **What This Means At iHouseDesign:** AI can assist diagnosis but cannot replace verification. Mujtaba asked: "I would Like to know have you fixed the Captcha using Codex?" AI tools can generate solutions, but a human must verify the result works in production, does not break existing functionality, and is properly documented. **Real Situation From The Database:** Mujtaba uses NotebookLM as a knowledge tool — he directed team members to upload SOPs there. He checked the reCAPTCHA implementation manually: "I saw the code too, the code for reCaptcha was on contact-ajax.php and it was V2 code." These are the right instincts. The gap is systematizing AI-assisted diagnosis into a repeatable workflow. **What You Should Do Differently:** Use AI to accelerate diagnosis, but always verify the result manually. When AI suggests a fix, document: (1) what AI was used, (2) what it suggested, (3) what you checked and confirmed, (4) what you changed. Verification is the human's job — never delegate it to the tool. ### 12. Speed and evidence > "If you don't screen-share with the person you're onboarding... then you're probably not 'leading'." > — Arseni Ria / IHD onboarding thread / 2026-06-02 **What This Means At iHouseDesign:** Speed without evidence creates rework. A fast fix that nobody can understand, verify, or repeat is not fast — it is technical debt. The most technically capable team members score high on execution but speed without documentation means the same problem gets solved differently every time. **Real Situation From The Database:** Arseni's feedback about screen-sharing was direct: "I can't force you to lead." The expectation is not just doing the technical work but showing it, explaining it, and leaving behind enough context that the next person does not need to reverse-engineer what happened. **What You Should Do Differently:** When you complete technical work, include enough evidence that someone reading the thread 3 months from now can understand what happened without asking you. A screenshot, a terminal output, a before/after URL, a written summary — these turn fast work into durable work. ### 13. Specific verification > "The person we're describing doesn't wait for a ticket. They see something like the Bluehost issue and start building a migration plan in a Sheet." > — Arseni Ria / Tia Lodewyk thread / 2026-05-29 **What This Means At iHouseDesign:** "I checked" must mean what was checked, where, and what result. A status update that says "hosting looks fine" is not useful. "Checked Bluehost 2 disk usage at https://my.bluehost.com — 78.6% of 100GB used, inodes at 62%, no alerts" is useful. The difference is specificity. **Real Situation From The Database:** The monitor_hosting_space_log shows Bluehost 2 at 78.6% usage on 162.241.24.245. This data exists in the system but is not consistently checked or reported. The difference between "I checked" and "I checked Bluehost 2 and here is the exact usage" is the difference between professional and amateur operations. **What You Should Do Differently:** Every monitoring check should produce a specific, quotable result. Not "checked hosting" but "checked Bluehost 2 disk: 78.6/100 GB (78.6%). Not "checked SSL" but "checked pizzulli.com SSL: valid until Dec 10, 2026, Pair Networks auto-renew." The specificity is the proof. ### 14. Founder independence > "What I need you to solve: how do we make ihousedesign survive when I'm not watching?" > — Arseni Ria / Tia Lodewyk thread / 2026-05-29 **What This Means At iHouseDesign:** The ultimate test of technical operations is: can the company function technically when Arseni is not watching? When a client emails tech@, does the response happen without Arseni redirecting? When a hosting account reaches 90% capacity, does someone notice and act without being told? **Real Situation From The Database:** The evidence shows a pattern: Technical VAs execute well when given clear instructions but do not consistently act on unassigned problems. Arseni's feedback — "next time we onboard a new project manager, do I have to tell Mujtaba, go to this folder, go to this subfolder... because to me that is babysitting" — captures the gap between executing and owning. **What You Should Do Differently:** Each week, identify one recurring technical task that currently requires someone to tell you to do it — and make it something you do automatically with proof. Turn it into a checklist. Set a reminder. Create a monitoring check. The goal is not to be asked again. ## Recurring Failure Patterns ### The "I Need Arseni To Decide" Problem A domain upsell, a routine SSL renewal, a hosting plan question — these are not decisions for Arseni. You have the technical knowledge to handle these independently. The pattern to break: forwarding anything that looks like a question without first answering it yourself. ### The Vague "Done" Problem "Fixed it." "All good." "Done." None of these mean anything without evidence. The database shows hundreds of open loops — tasks that were assigned but never visibly closed. Closure requires proof in the record. ### The No-Screenshot / No-Proof Problem A status update without a screenshot, URL, or log reference is not verifiable. When security issues are reported, the malware names and scan results must be visible in the thread, not just in an internal log that nobody reads. ### The Access-Was-Given-But-Not-Tested Problem Adding someone to WhatsApp, sharing a Google Drive folder, or granting Asana access is not complete until the recipient confirms they can use it. The gap between access granted and access working has caused repeated delays. ### The Seen-But-Silent Problem A suspended Google Cloud billing account affecting 9 active projects was posted in the team channel at 8:51 PM. Five people saw it. No response for 17 hours. The message had double checkmarks — it was read within minutes. Silence is not neutral. Silence on an urgent message is a failure of ownership. If you see a message involving a suspended account, a broken service, a failed payment, or any client-facing issue — acknowledge within one hour of seeing it. Not when you have the answer. Just: "I saw this, looking into it now" or "this needs Arseni's card, I cannot fix the payment side — please action." One sentence. That is the minimum. ### The Credential In Channel Problem The SOP states: do not paste passwords in Telegram group channels. Store in SI2 bot and reference it. This rule was added explicitly after a violation. Nine days later, the same violation occurred in the same channel — with the words "you can find passwords from SI2 telegram bot" written in the same message, followed immediately by a pasted password. The rule was known. The structural habit was not there. Credentials go to SI2 bot only. If you do not have access to paste from SI2, that is the correct state — it means you cannot accidentally violate the rule. ### The Private-DM Technical Decision Problem A technical fix discussed only in DM is invisible to the rest of the team. Even if the fix was correct, the organization cannot learn from it, audit it, or improve it. The decision must return to the shared record. ### The No-Rollback-Plan Problem Changing a client site without knowing how to undo the change is gambling. Every maintenance operation should include a documented rollback plan before execution. Shared hosting has limits — know what they are before you need to recover. ### The No-Owner / No-Next-Step Problem A tech@ email with no assigned owner is not being handled. A hosting alert with no next action is noise. Every incoming technical issue needs an owner, a diagnosis, and a next action within the same business day. ### The Escalated-Before-Diagnosis Problem Forwarding a technical issue to Arseni without having checked the basics — server status, error log, recent changes, known issue — wastes the founder's time. Diagnosis is free. Escalation costs someone the time to re-diagnose. ### The "Task Exists But Nobody Closes The Loop" Problem An Asana task was created, work was done, but the task remained open. A client email was answered but no log entry was created. A ticket was resolved but the resolution was not communicated. Work without closure is invisible work. ## What Arseni Actually Needs - **Clear diagnosis**: "What is the problem, what did you check, what did you find?" — 2026-06-02, Arseni - **Concise options**: "Option A costs this, takes this long, has this risk. Option B costs this, takes this long, has this risk." — standard expectation - **Ownership without babysitting**: "next time we onboard a new project manager... do I have to tell you, go to this folder, go to this subfolder?" — 2026-05-28, Arseni - **Proactive scope expansion**: "Next step is to check Bluehost 1 and Hostinger." — 2026-05-20, Mujtaba (this is exactly the right pattern) - **Fast escalation only when justified**: "I trust the technical team with simple things — register accounts, figure out how tools work." — 2026-05-29, Arseni - **Founder-independence**: "How do we make ihousedesign survive when I'm not watching?" — 2026-05-29, Arseni - **Urgent message acknowledgment within one hour of seeing it**: If a message involves a suspended account, failed payment, broken service, expiring certificate, or client-facing outage, acknowledge it immediately. Not when you have a solution. One sentence confirming you saw it and are acting on it. If you are unsure whether something is urgent, that uncertainty is itself the signal to respond. ## How To Report Technical Work Use this template for every technical issue, status update, or completion report: - **Problem:** One sentence describing the issue - **Evidence:** Screenshot, error log, or exact behavior observed - **System affected:** Hosting account, domain, CMS, email service - **URL / account / project:** Exact link or identifier - **Steps tried:** What you checked before escalating - **Result:** What happened after your fix or investigation - **Likely cause:** Your best diagnosis - **Risk level:** P1 (emergency) / P2 (degraded) / P3 (routine) - **Owner:** Who is handling this - **Next action:** What happens next, and by when - **Deadline:** When this needs to be resolved - **Proof of completion:** Screenshot, URL, log, or before/after ## What Done Actually Means - The issue was reproduced or clearly classified — a vague description was turned into a specific diagnosis with evidence. - The fix was applied or the correct owner was assigned — with a clear handoff message, not just a transfer. - The result was verified — a screenshot, terminal output, URL check, or before/after comparison was posted. - Screenshots, logs, links, or test results were posted in the shared thread — not in a private DM. - Asana, Telegram, or the shared record was updated with the resolution — the state in the system matches reality. - Any remaining risk was stated — "the SSL renews automatically, no action needed until December" is a risk statement. - Arseni does not need to ask what happened — the record speaks for itself. ## The Operating Standard Your job is to make technical problems visible, owned, diagnosed, and closed before they become founder emergencies. You are the most technically capable part of the operations team. That capability is wasted on ticket-turning. It is valuable when applied to ownership: diagnosing before escalating, documenting before forgetting, verifying before declaring done, and building systems that make the next emergency less likely. The database shows you can do the work. The gap is not skill — it is closure. Hundreds of open loops. Arseni having to ask whether clients were notified after a virus cleanup. These are not failure. They are the gap between technical execution and technical operations. Close the loop with evidence every time. Make the work visible. Make yourself replaceable — that is how you become indispensable. Every principle card includes an inline player with a relevant podcast clip from the local EcoThread corpus. These are full episodes — scan through to find the most relevant section. Leila Hormozi / Build with Leila Hormozi / Ep. 239 (11 min) — Diagnosis before escalation Leila Hormozi / Build with Leila Hormozi / Ep. 202 (17 min) — Evidence and closure Leila Hormozi / Build with Leila Hormozi (38 min) — Access verification / leadership Dan Martell / The Martell Method (20 min) — DRI, ownership Leila Hormozi / Build with Leila Hormozi / Ep. 60 (31 min) — Shared records Leila Hormozi / Build with Leila Hormozi / Ep. 346 (20 min) — Verification discipline Leila Hormozi / Build with Leila Hormozi / Ep. 306 (14 min) — Rollback planning Leila Hormozi / Build with Leila Hormozi / Ep. 138 (19 min) — Network verification Leila Hormozi / Build with Leila Hormozi / Ep. 260 (14 min) — Backup integrity Leila Hormozi / Build with Leila Hormozi / Ep. 361 (9 min) — Emergency severity Leila Hormozi / Build with Leila Hormozi / Ep. 364 (13 min) — AI as assistant Leila Hormozi / Build with Leila Hormozi / Ep. 250 (6 min) — Speed and evidence Leila Hormozi / Build with Leila Hormozi / Ep. 362 (11 min) — Specific verification Leila Hormozi / Build with Leila Hormozi / Ep. 252 (17 min) — Founder independence All podcast clips are sourced from the local EcoThread corpus (podcast_episodes table, feed 5950618 for Leila Hormozi, feed 203442 for Dan Martell). These are public MP3 enclosures. Each principle card includes a lightweight inline player. The full audio sources section at the bottom provides standard HTML5 audio controls for reference.