Documentation,
verified.

1. 60-minute working sessionWe go through your actual documentation: the spec, the PRD, the test plan, the handover doc that never got written. I ask the questions your team has stopped asking. No slide deck and no discovery questionnaire.
2. One-page triage note within 24 hoursA written summary of what I heard, the three gaps I would close first, and what each one costs you if you leave it. You own the document. It reads without me in the room, so you can send it straight to your team or your investor.
3. Recommended next moveA clear statement of what your documentation actually needs next, whether that is a rewrite, a template, a decision nobody has made, or nothing at all. If the answer is "you do not need me," I will say that on the call.

Founders, product leads and engineering managers whose documentation has become the bottleneck. You know something is wrong. You are not sure whether it is the spec, the process, the tool, or a decision nobody has made.

I spent my career in electronics and semiconductors, where a badly written requirement does not get fixed in the next sprint. It becomes a tooling change or a failed certification. That background makes me fast at spotting the sentence in your document that is going to cost somebody money. In software the same ambiguity surfaces at the next release. In hardware it surfaces after tooling.

1. You book. Send whatever exists: a spec, a PRD, a Notion page, a voice note. If you have nothing written down, book anyway and we start from the conversation.
2. I review before the call, so we do not spend the hour on context.
3. We talk for 60 minutes.
4. You get the written triage note inside 24 hours.

• A calendar slot overlapping IST business hours, or early and late by arrangement
• Whatever material you can share, ideally 24 hours ahead

1. Full markup of your documentI read your spec, PRD, SOP or test plan line by line and mark every gap: undefined terms, untestable requirements, missing tolerances, assumptions stated as facts, and steps no reader could actually follow. Comments go inline, in your tool.
2. Gap registerEvery issue found, sorted by what it costs you if it ships uncorrected. Each entry states the gap, where it is, why it matters, and the specific fix. Not "this section is unclear." Instead: "REQ-14 says 'low power' with no number. A supplier will quote against their definition, not yours."
3. Rewritten sample sectionI rewrite one section of your choice to the standard I would hold the whole document to, so you see the target rather than read about it.
4. 30-minute walkthrough callWe go through the register together, so your team learns the pattern instead of receiving a list they cannot apply next time.

Teams about to send a document to a supplier, a customer, an auditor, or a new hire, and quietly worried it is not ready. Also teams who inherited documentation from someone who left and cannot tell what is still true.

The specific reason your document will cause an argument later, identified before it causes one. Most documentation disputes trace back to a single sentence that two people read differently, and that sentence is almost always visible before anyone builds anything.

1. You send the document and tell me who reads it next: supplier, customer, auditor, engineer, new hire. The audience sets the standard.
2. Days 1 and 2: I audit and mark up.
3. Day 3: you get the gap register and the rewritten section.
4. The 30-minute call happens the same week.

• One document up to about 40 pages. Longer is fine, quoted separately.
• Comment or edit access in your tool, or a file I can mark up and return
• One line on who the document is for

1. Discovery passTwo structured sessions with your technical lead and one with whoever owns the commercial side. I extract the requirements that live in people's heads and have never been written down, which on most projects is the majority of them.
2. The PRDProduct definition, user and system requirements, interfaces, constraints, compliance and environmental targets, explicit out-of-scope statements. Every requirement numbered, atomic and testable. Anything that cannot be tested goes into a separate assumptions section instead of pretending to be a requirement.
3. Requirements traceability matrixEvery requirement mapped to its source (customer, standard, internal decision) and to the test that will verify it. This is the artifact that makes reviews short.
4. Open questions registerThe decisions your team has not made yet, stated plainly, with what each one blocks and who owns it. Handed over rather than buried.
5. Two revision roundsYou mark up, I close out. Twice.

Product and engineering teams at the point where the idea is proven and the build has to be specified. Usually before a supplier engagement, a funding milestone, or the first serious customer commitment.

The first version cannot be tested, so a supplier will interpret it against their own definition. The second version can only be passed or failed.

I use an AI-assisted drafting process that turns session transcripts and existing fragments into structured first drafts in hours rather than days. I still make every engineering decision and review every requirement. What the process removes is the typing, which is why two weeks is a date I can hold rather than one I miss quietly.

1. Week 1, days 1 to 3: discovery sessions, review of existing material.
2. Week 1, days 4 and 5: structured draft, requirements numbered.
3. Week 2, days 1 and 2: you review, I collect markup.
4. Week 2, days 3 to 5: revisions, traceability matrix, handover call.

• Roughly 4 hours of your technical lead's time across the two weeks
• Any existing material: diagrams, schematics, competitor research, customer emails, old specs
• A named decision-maker who can close open questions

1. Verification planEvery requirement mapped to a verification method: test, analysis, inspection or demonstration. Pass and fail criteria stated numerically before anything runs, so results cannot be argued into passing afterwards.
2. Test proceduresStep-by-step procedures someone can run without calling you: setup, equipment, sample size, and exactly what to record. Written to be repeatable by a person who did not design the product.
3. Verification and QA reportWhat was verified, how, against what criteria, with what result. Failures documented with the same rigour as passes, including root cause where determinable and the corrective action recommended.
4. Coverage and risk statementAn explicit statement of what was not verified and what risk that leaves open. Most reports omit this section. Most customers eventually ask for it.
5. Customer-ready summaryA two-page version your client, investor or auditor can read without a technical background.

Teams that have built something and now have to prove it works, to a customer, an auditor, an investor, or their own board. Also teams whose testing happened but was never written up, which is more common than anyone admits.

I write and structure the verification work. Whether I run physical tests depends on your setup and location. Usually your team runs them against my procedures and I own the analysis and the report. We agree that split before you pay anything.

Because a criterion written after the result is not a criterion. Stating the numbers before the test is the only thing that stops a marginal result from becoming a pass by consensus. This is standard practice in hardware verification and startlingly rare everywhere else.

1. Week 1: requirements review, verification plan, method selection.
2. Week 2: test procedures written, dry run with your team, execution begins.
3. Week 3: results analysis, report, coverage statement, handover.

• A requirements document or specification. If you do not have one, start with the PRD Writing service.
• Access to test data, results, or your test engineer
• Agreement on who runs the physical tests, settled before kickoff

1. Documentation auditWhat exists, what is stale, what is missing, and what is duplicated across three tools with three different version numbers. You get it as a map you can act on, with an owner and a next step against each gap.
2. Document architectureThe set of documents your team actually needs, how they relate, who owns each one, and when each gets updated. Sized to your team, not to an aerospace programme.
3. Templates and standardsWorking templates for each document type, with the house rules written into the template, so the standard travels without me.
4. AI-assisted drafting workflowThe process and prompt library your team uses to turn a conversation into a structured draft. Set up in your tools, loaded with your terminology, taught in working sessions rather than a slide deck.
5. Backfill of priority documentsThe two or three documents blocking something right now, written properly during the engagement.
6. HandoverA written operating guide so the system runs after I leave. If your team needs me permanently for this to work, I built it wrong.

Product and engineering teams between roughly 5 and 50 people where documentation has become the bottleneck. Symptoms: onboarding takes months, the same question appears in Slack every week, suppliers and customers work from outdated files, and one senior person is the single source of truth for everything.

Not a documentation-as-a-service retainer where I write your documents forever. The engagement has an end. Success is your team producing good documentation without me.

I built a 23-manual technical curriculum in a single semester using this approach: 20 embedded systems lab exercises and 3 FPGA and edge AI exercises, each with a full instructor manual covering objectives, setup, expected results, failure modes and grading. That volume is normally a multi-quarter programme. Content and technical accuracy stayed under my review throughout. Formatting, branding and consistency ran automatically.

1. Weeks 1 and 2: audit and architecture. You get the map, the gap list, and the document architecture.
2. Weeks 3 and 4: templates built into your tools, workflow trained with your team.
3. Month 2 onward: backfill. Priority documents written, your team writing alongside me.
4. Final two weeks: handover. Operating guide, final training, exit.

• An executive sponsor who can mandate the new process, because documentation systems die without one
• Access to your current tooling
• Roughly 3 hours per week of your team's time for sessions and review

1. Email founder@raystrat.com with one line on what is stuck.
2. I send an NDA and a slot that overlaps your hours.
3. Send whatever exists ahead of the call. If nothing is written down, we start from the conversation.