diy-tool — Boyce Data Science

Why this tool exists

Over about thirty years in healthcare and data science I built tools for the teams I worked with: checklists, cheat sheets, templates, spreadsheets with the formulas already in them, letters that only needed the names filled in, and code that did one job well. Nearly all of it lived in Word documents, Excel files, and folders on a shared drive. Converting those documents into pages that run in a browser, with an AI assistant doing the coding, is how the free tools on this site came to exist, and this page sets out the decisions I make each time so that you can make them for your own documents.

The knowledge in the document has to be yours. An AI assistant will build a page on any subject, including subjects you do not know, and when it is wrong you will not be able to tell. Bring a document you have used enough times to trust, review what the assistant builds the way you would review a colleague's draft, and the result can be shared with people who would never have asked you for the file.

Work through the stages in order. Each one explains a decision, records your choice, and the prompt stage assembles everything into prompts you can paste into an AI assistant. Your entries stay in this page until you save them to a file, and a saved file reopens here later. Nothing you type is transmitted anywhere.

If the document holds anything identifying about patients, participants, clients, or colleagues, take that out before you paste any part of it into this page or into an AI assistant. Paste the structure, the headings, the column names, and the wording, never the records.

Boyce Data Science. Under construction and not peer reviewed; suggestions are welcome at danielle@boycedatascience.com. Version .

The document you are starting from

Describe the document as it is used today. The questions here become the opening of the build prompt, and the more plainly you can say what a person does with the document, the better the first draft of the tool will be.

What kind of document is it?

What do you call it? Who uses it?

What does a person do with it, start to finish? One or two sentences in plain language, as if telling a new colleague.

What does the person fill in? What comes out at the end?

Paste the structure of the document Headings, column names, the questions, the boilerplate text, formulas in words. Leave out any real records. This is the part of the prompt with the most effect on the result, so give it the whole structure. What stays the same every time, and what changes? Fixed text and reference content become the page. Things that change become fields.

What the online version should do

A document becomes a tool when it does something a file cannot: guide a reader one step at a time, do the arithmetic, write the letter, or check the work. Choose what yours needs. Each choice carries a short note on what it asks of the build, because every feature is something you will have to test.

Anything else it should do

Start with less. The first version that people use will tell you what the second version needs, and a tool with three features that all work is more useful than one with ten features of which two are broken.

Where the entries live

This decision shapes everything else, and it is the one people skip. When someone types into your tool, the entries have to go somewhere, and the choices are set out below.

What JSON is, and why it keeps coming up

JSON (JavaScript Object Notation) is a plain text format for structured data. A saved file from a tool like this one is a JSON file: it holds every entry on the page with a label, in a form the page can read back. You can open one in a text editor and see your own answers. It is the usual choice for a save file because the page can write it and read it without any extra software, it is small, and it stays readable years later. A CSV file (comma separated values) is the equivalent for a single table, and opens in Excel. JSON holds nested things, such as a list of projects each with its own list of tasks, which a CSV cannot.

If the entries will ever include health information, personal details, or anything under a data use agreement, the safe choices are the first two: nothing stored, or a save file the person keeps on their own computer. Browser storage can be read by anyone with access to that device, and a server means an account, a privacy notice, security review, and someone responsible for it. A tool that stores nothing can still be useful to a clinician or a coordinator, because they keep the file.

What the tool produces, and in which format

Choose the outputs people will take away. The table underneath explains what each format is and what it takes to produce one, because some formats a browser writes on its own and others need a library, a piece of code the page loads from elsewhere.

File formats compared, and what each one takes to produce

Format	What it is	Who opens it	What the page needs
Print to PDF	The page itself, laid out for paper	Anyone	Nothing extra. A print stylesheet hides the buttons and expands collapsed sections. The person chooses Save as PDF in the print dialog.
Plain text or Markdown (.txt, .md)	Text with simple markup for headings and lists	Any editor; pastes into email, Word, GitHub, Notion	Nothing extra. The browser can write a text file by itself.
CSV (.csv)	One table as rows of comma separated values	Excel, Google Sheets, R, Python	Nothing extra to write. To read one in, a library such as PapaParse handles quoted commas and line breaks correctly.
JSON (.json)	Structured data with labels; the usual save file	The tool itself; also R, Python, and any editor	Nothing extra. Built into every browser.
Excel (.xlsx)	A real workbook, with sheets and typed cells	Excel, Google Sheets	A library such as SheetJS. Without it, offer CSV instead; Excel opens CSV directly.
Word (.docx)	A real Word document with styles	Word, Google Docs, LibreOffice	A library such as docx (docx.js). An alternative that needs no library is an HTML file, which Word also opens and which keeps headings and tables.
HTML (.html)	A web page, saved as a file	Any browser; Word	Nothing extra. Good for a report people will post or email, and the format of the tool itself.
Generated PDF (.pdf)	A PDF written by code rather than by printing	Anyone	A library such as jsPDF or html2pdf. Harder to get right than print to PDF; choose it only when the layout has to be exact.
Image (.png)	A picture of a chart or a result	Anyone	A charting library such as Chart.js can export its canvas; the rest of a page is harder to turn into an image.

About libraries

A library is loaded by one line in the page that points at a copy on a content delivery network, usually cdnjs or jsDelivr. That has three consequences to decide on. The page needs an internet connection the first time it loads the library. The line should name an exact version, so the tool does not change under you when the library updates. Where a page must work with no outside requests at all, for example inside a secure environment, the library's code has to be pasted into the file instead, which makes the file bigger but self-contained. Ask for the simplest format that does the job, and prefer the ones that need no library.

Notes on outputs

Where the tool will live

A single HTML file can be opened from a desktop, attached to an email, or put on the web. For sharing with the world there are two common routes, and a third for people who already run a website.

GitHub Pages and a website builder compared

	GitHub Pages	Code block on Squarespace, Wix, or WordPress	A file you send
Cost	Free for public repositories	Your existing site plan; code blocks and scripts may need a business tier	Free
Address	yourname.github.io/tool-name, or your own domain or subdomain	A page on your site, such as yoursite.com/tool-name	None
Scripts	Run as written	Depends on the builder and plan. Some published pages do not run scripts placed directly in a code block, and the fix is to wrap the whole tool in an iframe whose srcdoc attribute holds the page	Run as written when opened in a browser
Size	Files up to 100 MB; sites up to about 1 GB	Code blocks have a character limit that varies by builder; a large tool may have to be hosted elsewhere and shown in an iframe	Limited by email attachment rules
Updating	Replace the file in the repository; a few minutes to publish	Paste the new version into the block	Send it again
More than one file	Yes, any number	One block holds one file in practice	Awkward
Look of the page	Yours entirely	Inside your site's header, menu, and footer	Yours entirely
Version history	Built in, every change kept	None unless you keep copies	None unless you keep copies

Limits are a snapshot and change; confirm them at the links on the last stage before relying on them.

Putting a tool on GitHub Pages, step by step

Create a free GitHub account and a new public repository named for the tool.
Upload the HTML file and name it index.html, so the address of the repository shows the tool.
In the repository settings, open Pages, choose the main branch as the source, and save.
Wait a few minutes, then open the address GitHub shows. Every later upload of index.html replaces the live tool.
To use your own address, add a CNAME record at your domain registrar pointing a subdomain at the GitHub Pages address, then enter that subdomain in the Pages settings.

The GitHub guide on this site, GitHub, One Step at a Time, walks through each of these with the point-and-click route and the command-line route.

Embedding a tool in a Squarespace page

Add a page, then add a Code block to it.
Paste the whole HTML file into the block, and publish the page.
If the published page shows the tool but nothing in it works, the scripts are not running. Ask the assistant for a version that wraps the tool in an iframe with the page in the srcdoc attribute, and paste that into the block instead. The iframe runs the tool in its own frame, so the site's styles do not interfere with it either.
If the site has a fixed header, give the iframe a height tall enough for the tool, or ask the assistant to size it to its content.
If the block refuses the paste because it is too long, host the file on GitHub Pages and put a short iframe in the block that points at it.

Notes on hosting

The rules the build has to follow

These rules go into every prompt. They are the difference between a page that looks like it came from a template and one that reads as yours. Edit them freely; the defaults are the ones I have found hold up.

Standing rules Rules about the look Font, colors, how much on the screen at once, and whether it should match a site you already have. Words and phrasings to avoid, and what to use instead

The prompts

The first prompt builds the tool. The others are the passes that follow, and the order is deliberate: review the content before the code, test before publishing. Copy each one into your AI assistant, read what comes back as the expert on the content, and keep the prompts with the tool so the next revision starts from the same brief.

Prompt 1: Build the first version

Prompt 2: Review the content against the source

Prompt 3: Test it and fix what fails

Prompt 4: Package it for where it will live

Prompt 5: A revision, later

Before it goes out

Tick these off on the real file in a real browser. The assistant can say it tested something; you are the one who knows what the result should be.

What you found

Glossary and sites used

HTML: HyperText Markup Language, the file format of a web page. A tool like this one is a single HTML file holding its text, its styles (CSS), and its code (JavaScript).
CSS: Cascading Style Sheets, the part of the file that sets fonts, colors, and layout.
JavaScript: The programming language browsers run. It is what makes a page respond: calculating, checking, generating text, saving a file.
JSON: JavaScript Object Notation, a plain text format for structured data, and the usual format of a save file.
CSV: Comma separated values, a plain text format for one table, which Excel opens.
Library: Code written by others that a page loads to do one job, such as writing an Excel file. Loaded from a content delivery network or pasted into the file.
CDN: Content delivery network, a service that hosts copies of libraries at stable addresses, such as cdnjs or jsDelivr.
localStorage: A small store in the browser, on one device, that a page can write to and read from. Cleared when the person clears site data.
iframe: A window inside a page that shows another page. With a srcdoc attribute, the inner page's whole HTML is held in the attribute itself.
srcdoc: The attribute of an iframe that holds a complete page as text, used to embed a tool in a website builder's code block.
GitHub Pages: GitHub's free hosting for static sites: files in a repository are served as a website.
Repository: A folder of files on GitHub with its full history of changes.
Single-file tool: A tool whose HTML, CSS, and JavaScript are in one file, so it can be emailed, uploaded, or pasted whole.
Save file: A JSON file the tool writes with every entry on the page, which the same tool reads back.

Web sites used

Listed October 2026. Limits and features change; confirm at the source.

GitHub Pages documentation, including usage limits and custom domains
Squarespace Help Center: Code blocks
MDN: Window.localStorage
MDN: JSON
MDN: the iframe element and srcdoc
MDN: Blob, how a page writes a file for download
SheetJS, reading and writing Excel files
PapaParse, reading CSV files
docx, writing Word files
jsPDF, writing PDF files
Chart.js, charts
cdnjs and jsDelivr, where libraries are loaded from