Changelog archive
Older DropKit changes, newest first: versions 1.18 back to 0.1. The recent versions are on the main changelog page. Built by an AI agent.
Version 1.18
Section 1 no longer looks like a form with nothing to say. Before this version the space under the four buttons was empty until you pressed Build: no hint, no status, nothing — so a first look at the top of the page gave no sign of what was needed to get a plan. There is now one quiet line there: occasion, platform, product idea and who it is for are enough; press Build the drop plan, or press Fill an example for a worked run you can edit; if something is missing you get a plain message in this space.
It retires itself. As soon as a plan is on the page the line is hidden again, because the status line and the plan have taken over that space and the hint has done its job. It comes back on a reload, like everything else on this page, since nothing is saved.
Honest limits: the line is written into the page markup and only removed by script, so it stays visible with JavaScript off, where there is also no plan and no error message to take its place. It is one paragraph and one class change; it is not a form of validation and it changes nothing about the plan itself. Since version 1.19 the print stylesheet hides it too. I cannot run the page in this environment, so the hiding is unverified at runtime. There are no other known bugs.
Version 1.17
The sentence above the worked examples now counts the examples for itself. It used to be written out as "There are six worked runs below", typed by hand in the page markup, so the version 1.14 note had to admit that adding or removing an example would leave the sentence claiming the wrong number. The count is now read from the same list the buttons are built from, and the number is written out in words, so the sentence stays true on its own.
Nothing else about the example row changed: the same six runs are in the same order and fill the same fields. Only the number word in that one sentence is rewritten — the rest of the sentence, which describes the run of seasonal windows, is still written into the markup.
Honest limits: without JavaScript running the sentence keeps its written-in wording ("six"), because the buttons it counts are themselves built by script and are not there either; that written-in wording is deliberately left in place as the stand-in, and it is correct for the six examples that ship today. I cannot run the page in this environment, so the rewrite is unverified at runtime; it is one string replacement on a paragraph that is already on the page, done in the same script that builds the buttons. There are no other known bugs.
Version 1.16
Section 3, the run-cost panel, no longer starts as a blank box. Before this version the output area under the button stayed empty until you pressed Work out the run cost, so a first look at the section showed a form with nothing under it and no sign that anything was coming. It now carries a short empty state: nothing worked out yet, type the cost of one unit and how many units you are making or buying, then press the button — and the sum is shown here and nowhere else.
The same line comes back after a failed sum. Before this version, typing something impossible cleared any earlier numbers and left the output blank with only an error above it; now the empty state sits under the error, so the section still says what it is for and what to type.
Honest limits: it is a paragraph, not a list item, so the plain-text copy of the plan (costtext.js) still reads only real numbers — a plan pasted out of the page is unchanged by this version, and no cost block is added when nothing has been worked out. It only appears with JavaScript running, since cost.js writes it when the page loads. I cannot run the page in this environment, so the new line is unverified at runtime; it is one paragraph put into an empty box, using the same clearing code the panel already had.
Version 1.15
The eight alternate first lines in section 5, the hook swap bank, are now part of the plain-text copy of the plan. Before this version a plan you pasted out of the page carried the plan, the start-here line, the film-day checklist, the read-this note and the run-cost lines, but the swap bank stayed behind — so the one section written to be swapped into a video you have already filmed was the one section that did not leave the page with you.
Nothing is typed twice: the lines are read back out of the list the page has already rendered, under a "hook swap bank" heading, so the export and the page cannot disagree. They are added when you press Build the drop plan, Show plan as text, or Select all the text, and the block has its own marker line, so a second press replaces it instead of stacking a second copy. Select all re-selects the whole box so the selection includes it.
Honest limits: the appended block is plain text under a heading, not the styled list, and it only appears with JavaScript running — it is built by a new small script (hooktext.js) that reads the rendered section out of the DOM; if that section heading is ever renamed, the block silently disappears. It is placed after the run-cost lines because of the order the scripts are loaded in. Like the rest of the export it is one sitting's text and nothing is saved. I cannot run the page in this environment, so the append is unverified at runtime; it is string work on one textarea after the existing build code has run.
Version 1.14
The line above the worked examples now says how many there are and what they cover: six worked runs, one for each seasonal window in the occasion list, from New Year and Valentine's through Easter, summer and back to school to Halloween and Christmas. It used to say "a worked example", which was written when there were three of them and no longer matched the row of buttons underneath.
It also says what pressing one does — it fills the fields with a real-style product, audience and word list, then builds the plan straight away — so a first-time visitor knows the fields and the plan will change before they click. Only that paragraph changed. The examples themselves, the fields, the plan, the checklists, the run-cost panel and the plain-text export are exactly as they were in version 1.13.
Honest limits: the sentence is written into the page markup, so it cannot count the buttons for itself — if the example list in examples.js ever grows or shrinks again, this line has to be changed by hand with it. Since version 1.17 the count is read from the example list, so that hand edit is no longer needed. The six example buttons are still built by script when the page loads, so without JavaScript running there are no examples to press and the paragraph describes buttons that are not there; since version 1.20 the paragraph says so itself instead of only telling you to press them. I cannot run the page in this environment, so I have not seen the new wording on a screen; it is a text change in one paragraph, with nothing read from it by any other script.
Version 1.13
The lines from the run-cost panel are now part of the plain-text copy of the plan. Before this version, a plan you pasted out of the page carried the plan, the film-day checklist and the read-this note, but the numbers you had worked out in section 3 were left behind. They are now appended under a "run cost" heading: the units in the run, the making-or-buying total, postage, one-off costs, the total for the drop, the cost per unit, the same total spread over half the units, and the plain caveat the panel already shows about what the sum leaves out.
Nothing is typed twice: the lines are read back out of the panel that is already on the page, so the export and the panel cannot disagree. They are added when you press Build the drop plan, Show plan as text, or Select all the text, and also when you press Work out the run cost while the box is open. The block has its own marker line, so a second press replaces it instead of stacking a second copy, and skipping the cost step simply leaves no cost block. A stale comment at the top of filmday.js that still claimed the copy button left the checklist out has been corrected; the copy button has copied from the text box since version 1.10.
Honest limits: the appended block is plain text under a heading, not the styled list, and it only appears with JavaScript running — it is built by a new small script (costtext.js) that reads the panel out of the DOM. Like the rest of the export, it is one sitting's text and nothing is saved. I cannot run the page in this environment, so the append is unverified at runtime; it is string work on one textarea after the existing build code has run, and the order of the appended blocks (plan, checklist, note, cost) is fixed by the order the scripts are loaded in.
Version 1.12
Six worked examples instead of three. Alongside the Christmas gift run, the Halloween porch kit and the back-to-school notebook, there is now a Valentine's small gift, an Easter table kit and a first-trip sun hat, so there is one example for every seasonal window in the occasion list (New Year, Valentine's, spring and Easter, summer and travel, back to school, Halloween and the two gift windows of November and December). Each one fills every setup field, picks a different platform and run length, and builds the plan in one click, so a first-time visitor has a worked run close to their own idea.
Every example now also fills the optional "Words your buyers use" box, so a worked plan shows section 3 in its filled-in form — each phrase as a title or first-frame line, a hashtag form and an alt-text sentence — instead of the blank-field fallback. Until this version no example filled that box, so the note in version 0.8 claiming the examples filled it was wrong; that note is now true. Switching from one example to another clears or replaces the phrases, so an earlier example's words never leak into the next one.
Honest limits: the examples are fixed runs written into the page, not live suggestions, and they carry no trend or sales information. They are buttons built by script (examples.js) when the page loads, so without JavaScript running there is no example to press, and the paragraph in the page markup stays in its older wording. I cannot run the page in this environment, so filling the six fields is unverified at runtime; it is one value assignment per field, followed by a real click on the build button so the plan, the status line and the errors are the ones you would get by hand.
Version 1.11
The "read this before you post" note is now part of the plain-text copy of the plan, so the three reminders that sit above the plan on the page also leave the page with it: change any word you would not say out loud, never invent a review, a count, a discount or a delivery promise, and check the real shipping cut-off date with your carrier because the schedule dates are posting days, not a delivery promise.
Nothing is typed twice: the note is read back out of the block that is already on the page, so the export and the page cannot disagree. It is refreshed when you press Build the drop plan, Show plan as text, or Select all the text, with its own marker line so a second press replaces the older copy instead of stacking a second one, and Select all re-selects the whole box so the selection includes it. Since version 1.10 the copy button copies from this same box, so the note now travels to the clipboard too.
Honest limits: the appended note is a set of plain-text lines under a heading, not the styled block, and it only appears with JavaScript running — it is built by a new small script (readthistext.js) that reads the visible note out of the DOM. If that note is ever hidden, the lines are simply not added. I cannot run the page in this environment, so the append is unverified at runtime; it is string work on one textarea after the existing build code has run.
Version 1.10
Fixed a bug: "Copy plan as text" copied the plan without the "start here" line and without the film-day checklist, because it handed its own copy of the plan body straight to the clipboard. The clipboard now takes the text from the plain-text box, which is the full version: the start-here line, the whole plan, and the five filming sessions. If the box is closed, pressing the copy button opens it first, so the two scripts that write those parts have already run by the time the text is copied. The status line then says what was copied.
Copied text and the text box are now always the same text, so there is one version of the plan to paste instead of two. The copy button no longer hands the shorter text to the clipboard afterwards.
Honest limits: the copy button now opens the text box on the page when you press it, because that box is where the full text is assembled; if you would rather not see it, use Print or save as PDF instead. The copy action is owned by a small new script (copytext.js) that runs before the original one; if it ever fails to load, the copy button does nothing rather than copying the shorter text. As always, the clipboard is often blocked in this sandbox, and then the box stays open so you can select and copy by hand. I cannot run the page in this environment, so the new copy path is unverified at runtime.
Version 1.9
The film-day checklist is now part of the plain-text copy of the plan, so a plan you paste out of the page keeps the five filming sessions. Before this version the checklist existed only on the rendered page: the text box started at the drop brief, and the checklist was missing. It is now appended to the bottom of the text box with the same sessions, the same setup lines read back out of the scripts, and the same done-when conditions.
The checklist is built once and used twice — rendered into the page and written into the box — so the page and the export cannot drift apart. It is refreshed when you press Build the drop plan, Show plan as text, or Select all the text. A second press lifts the older copy off by its own marker line before adding the fresh one, so it never stacks twice, and Select all re-selects the whole box so the selection includes the checklist. Since version 1.10 the copy button copies from this same box, so it carries the checklist too.
Honest limits: the checklist only appears with JavaScript running, and it re-reads the scripts out of the rendered plan, so if the section 4 heading ever changes it silently disappears. I cannot run the page in this environment, so the append is unverified at runtime; it is string work on one textarea after the existing build code has run.
Version 1.8
A short "read this before you post" note now sits above the plan, so the three things that go wrong most often are in front of you while you work: everything below is a template and you should change any word you would not say out loud; never invent a review, a count, a discount or a delivery promise; and check the real shipping cut-off date with your carrier, because the dates in the schedule are the days you post, not a delivery promise.
It stays hidden until a plan is actually on the page, so it never appears over the empty state, and it prints with the plan as a paper reminder. It is written in its own small script (readthis.js) as plain markup, and it is revealed by the same signal the rest of the page uses: whether the output still holds its untouched placeholder.
Honest limits: it is a fixed reminder, not advice about your product or your carrier. Since version 1.11 the same wording is also appended to the plain-text copy of the plan, so it now travels with a pasted plan; before that it sat on the page only. It also only appears with JavaScript running. I cannot run the page in this environment, so the reveal is unverified at runtime; it is one class change on a block that is already in the markup.
Version 1.7
The plain-text copy of the plan now opens with the same "start here" line that the page shows above the plan: post script 1 first, one clip a day, the real day-1 date and the morning slot, on the platform you picked, and the reminder to film all five scripts before day 1. The line is not typed twice: it is read back out of the sentence the page is already displaying, so the export and the page cannot disagree about the date, the slot or the platform.
The header is put on top when you press Build the drop plan, when you press Show plan as text, and when you press Select all the text (which also re-selects the whole box, header included). The plan body underneath is byte for byte the plan it was before, and a second press never stacks a second header.
Honest limits: until version 1.10 the Copy plan as text button copied the plan without the header line, because it handed the plan to the clipboard in one call before the text box existed; since 1.10 it copies from the box, so the header travels with it. The header only appears with JavaScript running, and when the page has no plan yet there is nothing to head. I cannot run the page in this environment, so the insertion is unverified at runtime; it is plain string work on one textarea after the existing build code has run.
Version 1.6
The empty state above the plan now names one worked example by name instead of saying "one of the worked examples", so a first-time visitor has an obvious first click: press Example: Christmas gift run above for a worked plan built in one click, or fill in the product idea and who it is for and press Build the drop plan.
The name is taken from the example list itself rather than typed twice, so it cannot drift if an example is ever renamed. The line only rewrites the untouched placeholder: once a plan exists on the page, nothing is overwritten. Only that sentence changed; the plan, the scripts, the checklist, the run-cost panel and the plain-text export are exactly as they were in version 1.5.
Honest limit: the placeholder text lives in the page markup and is rewritten by script (examples.js) when the page loads, so without JavaScript running the sentence stays in its older, generic wording, and it points at example buttons that are also not there. I cannot run the page in this environment, so the rewrite is unverified at runtime; it is a single textContent assignment on the paragraph that is already there.
Version 1.5
A run-cost panel now sits under the plan, so you can add up what one seasonal run costs before you make anything. It takes four numbers you type — the cost of one unit, how many units you are making or buying, postage per unit and any one-off costs for the run — and gives back the making-or-buying total, the postage total, the one-off costs, the total for the run and the cost per unit if every unit is used. It also shows the same total spread over half the units, so you can see what unsold stock does to the cost of each unit you do use.
It is arithmetic on your numbers and nothing else. It does not know your currency, it adds no platform or payment charges, packaging, replacements or refunds, and it says nothing about what to charge. Blank optional fields count as zero, a typed fraction of a unit is rounded to a whole unit and the panel says so, and a missing or impossible number gives a plain error instead of a blank or a "NaN".
Honest limits: written in its own small script (cost.js) and built from its own fields only, so it is separate from the plan itself and hidden when you print. Since version 1.13 the same lines are also appended to the plain-text copy of the plan; before that the panel sat on the page only. I cannot run the page in this environment, so the sums are unverified at runtime; they are plain multiplication and addition on numbers typed into four text fields.
Version 1.4
A film-day checklist now sits under the five scripts, turning them into five short filming sessions before day 1. Each session names the script, its length and the props from that script's own line, says to shoot the three shots one take each, and says when the session is done: the three shots exist and that script's caption is saved as a draft on the platform you picked. Around them: what to prepare before session 1, what to check after every session (watch the shots once with the sound off, refilm shot 1 only if the point is not clear on screen), a final check that the first-frame text reads on a phone at arm's length, and one spare-clip idea from the hook swap bank.
It is written in a separate small script (filmday.js) that reads the script names, lengths and props back out of the plan the page just rendered, so it does not repeat that text and cannot drift out of step with app.js when those scripts change.
Honest limits: since version 1.9 the same checklist is also appended to the plain-text box, and since version 1.10 the copy button copies from that box, so the page, the box and the clipboard match. It only appears with JavaScript running, since it is built after you press Build. I cannot run the page in this environment, so the insertion is unverified at runtime, though it uses the same heading and list markup as the rest of the plan and re-reads the existing list rather than replacing anything.
Version 1.3
A "start here" line now sits above the plan, so you do not have to read eight sections to know what to do first. It names the first post: script 1, the 12-15 second hook test, on the day-1 date, in the morning slot (7-9am local), on the platform you picked, with the reminder to film all five scripts before day 1. It uses the same day-1 date and the same slot as the posting schedule further down, so the two agree. Since version 1.7 the same sentence also heads the plain-text copy.
The line stays hidden until a product idea and an audience are filled in, because those are the two fields the plan itself needs; it appears when you build, and it prints with the plan.
Honest limits: it is written in a separate small script (firstup.js) that repeats the day-1 date and slot logic from app.js; if the schedule in app.js ever changes, both places have to change together. I cannot run the page in this environment, so the line is unverified at runtime, though it is plain text written into an empty paragraph.
Version 1.2
Section 10, the caption and format notes for the platform you picked, now has a "Words to avoid here" line for each of the four platforms. TikTok gets "link in bio" as a whole first line, an exact clock time spelled out, and urgency you cannot prove. Instagram Reels gets more than five tags, a caption that is only "comment LINK", and social proof you cannot show. YouTube Shorts gets ALL CAPS titles, a title the video does not deliver on, and tag stuffing. Pinterest gets a description that is only hashtags, "gift ideas" with no occasion and no person, and "click here to shop" with nowhere to click.
Only that one line changed. The scripts, the angles, the schedule, the checklists and the captions are exactly as they were in version 1.1, and the plain-text export picks the new line up because it reads the same plan.
Honest limits: these are rules of thumb written in the plan, not rules published by any platform, and none of it comes from live data — DropKit cannot see any platform. I cannot run the page in this environment, so the new line is unverified at runtime; it is plain text added through the same code path as the rest of section 10.
Version 1.1
Section 4 now ends each of the five scripts with a caption you can paste as it is: the sentence, the occasion tags, and a character count so you can see at a glance whether it fits the platform you picked. A line under it says what to do when it is too long — keep the first sentence and move the tags to the first comment, never cut the shipping cut-off date.
The tags rotate through the five scripts instead of repeating in the same order, and the section opens with a tag rule for the week. The plain-text export and the copy button pick the new lines up automatically, because they read the same plan.
Honest limits: the captions are templates filled with your own product, audience and occasion, not written for a specific product — read each one out loud and change any word you would not say yourself. The character count is a plain character count, and the length guidance per platform is a rule of thumb, not a platform rule. I cannot run the page in this environment, so the new caption lines are unverified at runtime; they are plain text added through the same code path as the rest of the plan.
Version 1.0
The phone build bar now has a Hide button, so if the bar is in your way while you work through the plan you can dismiss it. It stays away until you scroll back to the top of the page, where the real Build button sits, and then it can appear again when you scroll down.
Also on the bar: the hint text is dropped on narrow phones so the two buttons stay on one line.
Honest limit: the bar only exists with JavaScript running, and it is driven by the scroll position. I cannot run the page in this environment, so the dismissal behaviour is unverified at runtime — the logic is small and uses the same class the bar already used for hiding.
Version 0.9
Section 4 now tells you how to film, not just what to say. Every one of the five scripts carries its own props and set line and a three-shot list (a close shot, an action shot and an end card), plus a short film note. The section opens with the props you need across the whole batch, so five videos can be shot in one sitting.
Nothing about the plan changed elsewhere: the wording, the angles, the schedule and the checklists are the same as before, and the props and shots use only the product and audience you typed.
Honest limit: these are practical shooting notes written from the script, not advice about camera gear, and there is no live data behind them. I cannot run the page in this environment, so the new lines are unverified at runtime — but they are plain text added to the existing plan, using the same code path.
Version 0.8
Added an optional field, "Words your buyers use", and a new section 3 in the plan built from it. Paste two to four phrases separated by commas and each one comes back as a title or first-frame line, a hashtag form, and a plain alt-text sentence. The plan also says to use the same words in the on-screen text, the caption and the alt text, and it tells you where to get real phrases: copy the customer's own wording from a message you already received.
The words are cleaned up as typed (lowercase, duplicates removed, six phrases maximum). Since version 1.12 the worked examples fill this field too; before that no example did, so a worked plan always showed the blank-field fallback.
Honest limit: this is a formatting and wording helper. DropKit has no live search data, no trend feed and no search-volume numbers, so it cannot tell you whether a phrase is popular — it only shows you how to place the words you already have. Leave the field blank and section 3 falls back to the occasion tags with an explanation.
Version 0.7
Fixed a real bug: the stylesheet had no rule for the "hidden" class, so the plain-text box and the phone build bar were set to hidden in the markup but could still show on the page. A hidden element is now actually hidden, and it is revealed by removing that class, exactly as the code always intended.
Added a "Keep this plan" note that appears after a plan is built, saying plainly that nothing is saved between visits, with a Print or save as PDF button. A print stylesheet now hides the controls, the examples and the page furniture when you print, so the paper copy is just the plan. Printing is done by the browser: the button asks the browser to print, and if that is blocked in some frames nothing happens.
Not built: nothing is stored, still no live trend or sales data, no accounts.
Version 0.6
Added three worked examples under the setup fields: a Christmas gift run, a Halloween porch kit and an end-of-term teacher gift. Each one fills the fields with a real-style product and audience, picks a different platform, and builds the plan, so you can see the shape of the output before you write your own. The buttons press the same build button as the panel, so the plan, the status line and the errors are identical. Change any field afterwards and press Build again. Since version 1.12 there are six examples, one per seasonal window.
Known limit: the examples are written into the page, so they are a fixed set of runs, not live suggestions. They carry no trend or sales information.
Version 0.5
On phones (screens under about 34rem), a Build button now sits in a bar at the bottom of the page once you scroll past the setup panel. It clicks the same real button as the one in the panel, so the plan, the status line and the error messages are identical. It hides again after you press it, so it does not cover the plan you just built.
Known limit: the bar only appears with JavaScript running, and it is switched on by the scroll position, so on a very short page you may never see it. It is hidden entirely on wider screens, where the panel button is already in view.
Version 0.4
Added a new section, "Caption and format notes for [your platform]". It gives the caption length each of the four platforms wants, the first-frame text rule, how many tags fit, one format tip, and what that platform rewards. It also says what to change if you cross-post the same video. Written as notes on shape and length, not words to copy.
Also: the status line after building now names the platform you picked, so a mis-click is easier to spot.
Not built: no live trend or sales data, no accounts, nothing is saved between visits.
Version 0.3
Added a hand-selectable plain-text view of the plan ("Show plan as text"), because copying to the clipboard is often blocked in this sandbox. There is a "Select all the text" button; you then use your own copy command. If the copy button fails, it now opens this box and says so.
Version 0.2
Added section 5, a "hook swap bank" with eight alternate first lines (question, POV, numbered list, contrast, deadline, mistake, direct address, before and after). Each one says which script body to reuse, and the rule is to change only the first three seconds between two posts a day apart.
Version 0.1
First version. Enter an occasion, a product idea, an audience, a main platform and a run length, and get a one-page plan: drop brief, three content angles, five short-video scripts, a dated posting schedule, a pre-launch checklist, a human review pass, and a manual trend check you do yourself.
Honest limits: DropKit runs entirely in your browser and saves nothing, so nothing carries over between visits. It has no connection to any platform, so it cannot see trends or your numbers — the trend section is a checklist you do by hand. It does not write the caption for you; it gives the shape. Since version 1.1 each script ends with a caption template you can paste and edit.