DEV Community: Mustafa Tarabya

new Date('2026-03-01') is 28 February if your user is in California

Mustafa Tarabya — Thu, 10 Sep 2026 16:53:22 +0000

We build a tool that turns a few form fields into a finished resignation or notice letter.
The single most important string in that output is a date. A resignation letter states your
last working day, and that date is the thing your employer acts on.

So the date formatting code is four lines and it is the most dangerous four lines in the
feature.

function formatDate(value) {
  if (!value.trim()) return '';
  const d = new Date(value);
  if (Number.isNaN(d.getTime())) return value.trim();
  return d.toLocaleDateString('en-GB', { day: 'numeric', month: 'long', year: 'numeric' });
}

Reasonable looking. Here is what it does.

The bug

An HTML <input type="date"> gives you "2026-03-01". Feed that to new Date and run it
in Los Angeles:

$ TZ=America/Los_Angeles node -e "console.log(new Date('2026-03-01').toLocaleDateString('en-GB',{day:'numeric',month:'long',year:'numeric'}))"
28 February 2026

Same code in Helsinki:

1 March 2026

The user picked 1 March. The letter says 28 February. Nothing threw, nothing logged, and
the developer in a positive UTC offset never sees it.

Why

ECMAScript specifies that a date-only ISO string is parsed as UTC. "2026-03-01"
becomes midnight UTC. toLocaleDateString then renders it in the runtime's local zone. In
Los Angeles, midnight UTC on 1 March is 4pm on 28 February.

Any format that is not date-only ISO is parsed as local time instead:

$ TZ=America/Los_Angeles node -e "console.log(new Date('2026/03/01').toDateString())"
Sun Mar 01 2026

Slashes give the right answer here and dashes give the wrong one, but only half of that is
specified. The specification pins down exactly one thing: a date-only ISO string is UTC.
Everything else, 2026/03/01 included, falls through to an implementation-defined fallback
parser, so it happens to work in V8 and you cannot lean on it. Do not read this as "use
slashes". Read it as "do not hand a string to Date at all". The UTC half is guaranteed by
the spec, and it hits every negative UTC offset, which is the whole of the Americas.

The consequence for the product is specific and bad. Someone resigning on the first of the
month sends a letter naming the last day of the previous month. There is no crash to
report, so the first time anyone finds out is a conversation with HR.

The second failure: invalid dates that are not invalid

The Number.isNaN guard implies dates either parse or fail. Try 30 February:

$ TZ=America/Los_Angeles node -e "console.log(new Date('2026-02-30').toDateString())"
Sun Mar 01 2026

Not Invalid Date. Date rolls the overflow forward, so an impossible day silently
becomes a real day in the following month. The guard never fires, because there is nothing
to catch. A typed-in date of 2026-02-31 produces a confident, wrong, plausible answer.

The other side of the same coin is that real invalid input does need handling, but not by
rejecting it. Somebody typing end of March into a free text field is being reasonable.
The fallback in that function returns their string untouched, and I would keep that. Do not
punish a human for not using the date picker. Just do not confuse "I could not parse this"
with "this parsed to something sensible".

The third failure: two weeks is not 1,209,600,000 milliseconds

A notice-period feature wants to offer "two weeks from today". The tempting arithmetic:

const end = new Date(start.getTime() + 14 * 86400000);

Run it across a daylight-saving boundary:

$ TZ=America/Los_Angeles node -e "
  const s = new Date(2026, 9, 25);
  console.log(new Date(s.getTime() + 14*86400000).toDateString());
  console.log(new Date(2026, 9, 25 + 14).toDateString());
"
Sat Nov 07 2026
Sun Nov 08 2026

Two weeks after 25 October 2026 is either 7 or 8 November depending on which arithmetic you
used. The millisecond version loses a day because the clocks go back on 1 November and one
of those "days" was 25 hours long.

Adding days is a calendar operation. Adding milliseconds is a physics operation. They agree
most of the year, which is what makes this survive code review.

The fix

Stop letting Date parse strings, and stop letting UTC into a calendar calculation.

function formatDate(value) {
  const v = String(value).trim();
  if (!v) return '';

  const m = /^(\d{4})-(\d{2})-(\d{2})$/.exec(v);
  if (!m) return v;                       // "end of March" passes through untouched

  const [, y, mo, d] = m.map(Number);
  const dt = new Date(y, mo - 1, d);      // local construction, no UTC shift

  // catch the silent rollover: 2026-02-30 comes back as March
  if (dt.getFullYear() !== y || dt.getMonth() !== mo - 1 || dt.getDate() !== d) return v;

  return dt.toLocaleDateString('en-GB', { day: 'numeric', month: 'long', year: 'numeric' });
}

Three changes, each fixing one of the failures above:

Match the format explicitly. If it is not YYYY-MM-DD, it is not a date we are willing to interpret, so it goes through as typed.
Construct from components. new Date(y, mo - 1, d) builds a local date. No parsing, no UTC, no offset arithmetic.
Round-trip the result. Read the fields back off the constructed date and compare. If they disagree with the input, an overflow happened and the input was never a real date.

For date arithmetic, use component maths for the same reason:

const end = new Date(start.getFullYear(), start.getMonth(), start.getDate() + 14);

The runtime handles month and year boundaries and, critically, handles DST, because you
asked for a calendar day rather than a fixed duration.

The general rule

Date conflates two things that behave differently: an instant on a timeline, and a day on
a calendar. Timestamps, expiry, ordering, "how long ago" are instants, and UTC is correct
for all of them. A birthday, a deadline, a last working day is a calendar day, has no time
component, and does not exist on a timeline until you attach a zone to it.

Almost every date bug we have put live came from storing a calendar day as an instant and
then rendering it somewhere else.

Two habits that catch it cheaply:

Run your test suite under at least one negative UTC offset. TZ=America/Los_Angeles npm test in CI takes no extra time and turns this entire class of bug into a red build. If your only tests run in UTC, or in a European zone, this bug is invisible by construction.
Test a DST boundary date on purpose. Pick the specific weekend your target zone changes and put it in a fixture. It is the only way that arithmetic gets exercised.

We found all three of these in one small function whose whole job was to print one line. The
resignation letter template tool it
belongs to is free and needs no account, and the date it prints is now the date the person
actually picked, which was always the only requirement.

Our regex found 199 records in a 1,723-record corpus and reported no errors

Mustafa Tarabya — Mon, 07 Sep 2026 20:41:43 +0000

We maintain a corpus of 456 role-specific resume examples in TypeScript. Someone asked me
what a good bullet point actually looks like, and rather than answer from taste I decided
to measure the thing I already had.

Fifteen minutes later we had a script, a set of numbers, and a conclusion. The conclusion
was wrong, because the script had silently read about twelve percent of the data.

This is a post about that failure mode, and then about the numbers I got once the script
worked.

The corpus

Thirty-one TypeScript files, each exporting an array of role objects. One role looks roughly
like this:

{
  slug: 'cloud-architect',
  title: 'Cloud Architect Resume',
  category: 'Information Technology',
  sampleData: {
    summary: '...',
    experiences: [
      {
        company: 'Amazon Web Services',
        position: 'Senior Cloud Architect',
        description: '- Designed multi-region architecture...\n- Led migration of...',
      },
    ],
    skills: [...],
  },
  tips: [...],
}

The interesting field is description. It holds a newline-delimited list of bullets as a
single string, so the whole corpus of bullets is sitting there in source, greppable,
without a database or an export step.

Version one

const descs = [...text.matchAll(/description: '((?:[^'\\]|\\.)*)'/g)].map(m => m[1]);

Nothing exotic. Match description:, then a single-quoted string, allowing escapes so an
apostrophe inside the text does not terminate the match early.

It found 199 description strings. I did not question that, because I had no prior for what
the number should be. 199 sounded like a lot of text. We computed medians off it, looked at
the opener distribution, and started writing.

The number that saved me was on a different line of the same output: roles 456. The slug
count was fine. So 456 roles between them had 199 job descriptions, which would mean the
overwhelming majority of roles had no work history at all. I knew that was false, because
I had rendered these pages.

Why it read twelve percent

Prettier. That is the whole answer.

Some of these files were formatted at a width that keeps the value on the same line:

description: '- Led enterprise sales team of 30+...',

Others were formatted with the value pushed onto the next line:

description:
  '- Led enterprise sales team of 30+...',

The pattern had a literal space after the colon. Every record in the second shape failed to
match. Not with an error. Not with a warning. The regex simply found fewer things, and a
regex that finds fewer things looks exactly like a regex running over a smaller corpus.

// before
/description: '...'/g
// after
/description:\s*('...'|"...")/g

Adding \s* took the count from 199 to 1,723.

The general shape of this bug is worth naming, because it is not really about regexes.
A parser that silently skips malformed input converts a crash into a wrong answer. A
crash costs you ten minutes. A wrong answer costs you however long you spend believing it,
which in my case included a first draft of this post.

Two habits that catch it:

Have an expected order of magnitude before you look at the output. 456 roles times three jobs each is well over a thousand. 199 should have been alarming on sight.
Cross-check one extracted count against a different one from the same run. Slugs and descriptions come from the same files through different patterns. When one is plausible and the other is not, the pattern is the suspect, not the data.

What the corpus actually looks like

With the parser fixed: 1,723 description blocks, of which 1,267 use the bullet format,
yielding 3,815 individual bullets.

Length. Median 14 words. The 10th percentile is 11, the 90th is 17, the full range is
7 to 25. That is a tighter distribution than I expected, and it is not the product of a
style rule, because there was no style rule. It is what a claim plus its evidence happens
to cost in English. Under about ten words you have stated a duty. Over about twenty you
have written a paragraph that gets skimmed.

Numbers. 89.0 percent of bullets contain at least one digit. 1,081 contain a percentage,
555 contain a currency amount. That leaves 418 bullets with no number in them at
all, and reading a sample of those is instructive: they are the ones describing scope
rather than outcome, which is a legitimate thing to describe when you cannot quantify it.
The failure is not "has no number", it is "has neither a number nor a specific".

Verbs. 332 distinct opening words across 3,815 bullets. The top ten (managed,
developed, led, built, created, designed, implemented, conducted, reduced,
manage) account for 40.9 percent of all openers. 143 verbs appear exactly once.

That distribution is the interesting part. It is not flat and it should not be flat. A long
tail of one-off verbs (architected, migrated, authored) carries the specificity, while
a small head of common verbs carries the ordinary work. A resume where every bullet opens
with an unusual verb reads like a thesaurus exercise.

Weak openers. 149 bullets, under five percent, begin with supported, assisted or
similar. Zero begin with responsible for. That one is a genuine consensus in the corpus
rather than something I enforced.

Density. The median role shows three bullets per position, never more than four. The
456 summaries run a median of 37 words, with the 10th to 90th percentile band sitting
between 29 and 45.

Duplicates: zero. Not one bullet text appears twice across 3,815. I checked because I
assumed generated-looking content would have collisions, and finding none told me the
corpus was written per role rather than stamped from a shared list.

The part that transfers

The measurement I would suggest to anyone writing bullets for their own history, since it
takes a minute and needs no tooling:

Count words. If a bullet is under ten or over twenty, it is probably a duty or a paragraph.
Look for the digit. If there is none, check there is at least a proper noun, a system name, or a scale.
Read only the first word of every bullet, top to bottom. If the same verb appears three times in one job, two of those bullets are describing the same thing.

Number three is the one that finds real problems fastest, and it is the same trick as the
script: look at one narrow projection of the data instead of reading all of it.

The corpus these numbers came from is public. It is the set of
resume examples on the builder I run, organised by
role, free to open and free to preview without an account. It was not written in order to
be measured, which is exactly why the measurements were worth taking.

And the script stayed in the repo, with the \s* and a hard assertion that the description
count is within an order of magnitude of the role count. A checker that can quietly read
twelve percent of its input will do it again.

Our site served every URL the same 3,780 bytes, and Google believed it

Mustafa Tarabya — Mon, 07 Sep 2026 20:40:49 +0000

Checked with a Googlebot user agent one morning: every single URL on our site returned the
same 3,780-byte shell. Same <title>, zero <h1>, zero body text. The homepage, a blog
post and a product page were byte-identical before JavaScript ran.

Search Console agreed with the crawler rather than with us. Of 741 URLs, 116 had earned a
single impression in 28 days, and a landing page that had been live for five months was
still reported as "URL is unknown to Google".

Here is what I actually learned fixing it, including the two things that cost us the most
time.

Google does render JavaScript. That is not the point.

The standard reply to this problem is "Googlebot executes JS now, you are fine." It does.
Several of our pages were indexed, so rendering clearly happened.

But rendering is a separate, budgeted queue. A domain with little authority does not
get much of that budget. So the practical question is not "can Google render our page", it
is "will Google spend its budget rendering this page, today, before it decides what the
page is about".

There is a second problem that has nothing to do with rendering: 741 URLs that are
byte-identical before render look like duplicates. You are handing a duplicate-content
signal to the crawler and hoping the render queue fixes your first impression.

What we built, and what we deliberately did not

We wrote a post-build script that injects a real <head> into each generated HTML file:
title, description, canonical, robots, Open Graph, Twitter.

Head only. The body stayed exactly as the SPA served it. That was deliberate:

No hydration flash.
No risk of a static copy drifting out of sync with what users see.
Nothing that could be read as cloaking, because the static markup is a subset of the rendered markup, not a different page.

Every value is read from the same source the React page reads. Where a title is a literal
inside a component, the script extracts it from that component's source rather than having
anyone retype it. A number retyped in two places is a number that will disagree with itself
eventually.

Trap 1: react-helmet-async deletes tags you did not mark

Our shell had static <meta name="description"> in index.html. Helmet sets its own on
mount. The assumption was that the later one wins.

What actually happens: on its first commit, Helmet removes every tag carrying data-rh
and re-inserts its own. Tags without that attribute survive. So the static tag stayed,
Helmet's tag was added, and the page went out with two descriptions, with the static one
first in the head, which is the one scrapers and crawlers read.

Every blog post on the site was advertising the generic homepage copy.

The fix is to mark the tags Helmet actually emits:

<meta data-rh="true" name="description" content="..." />

With one sharp edge: only mark tags Helmet will re-add. A data-rh tag that Helmet does
not re-insert gets deleted on mount and never comes back. We marked og:image and lost our
share image everywhere until we worked out why.

The matching bug in our own script: the replace was written as a regex keyed on attribute
order, <meta name="description" ...>. The shell writes <meta data-rh="true" name="description" ...>. It silently matched nothing. Match on a tag containing the
key, never on attribute order.

Trap 2: the script read the sitemap, and nothing regenerated the sitemap

This one cost the most time and had the least to do with SEO.

The prerender script takes its URL list from sitemap.xml. Reasonable: one source of truth
for what exists.

But npm run build did not include the sitemap generator. It ran vite, then redirects,
then the crawl index, then prerender. The sitemap was generated by a separate command
somebody had to remember to run.

So we added a new route, built, deployed, and the page was live and completely absent from
the prerendered set. No error. No warning. The build exited 0. The route simply was not in
the list, so it was never processed, and it went out with the generic shell head.

We burned two builds assuming the code was wrong before checking whether the input was
stale.

If a build step consumes a generated artifact, that artifact's generator belongs in the
same build command. Otherwise you have an ordering dependency that lives only in
somebody's memory, and it fails silently rather than loudly.

Trap 3: a dead ternary that read as intentional

We found this while adding static content for a specific route:

const key = m ? m[1] : route === '/some-route' ? null : null;

Both branches return null. It was presumably mid-refactor when someone got interrupted.
It looks purposeful enough to skim past in review: there is a route name in it, so it
reads like a handled special case.

The effect was that the route fell through to a generic fallback body, which contained
none of the terms the page existed to rank for. The page had been quietly pointless for
weeks.

Grep your codebase for ? null : null. I will wait.

What I would tell myself at the start

Verify with curl and a crawler user agent, not with your browser. Your browser runs the JavaScript. That is exactly the thing you are trying to see past.
Static head, dynamic body, always from one source. Two hand-maintained copies of the same string are a future contradiction.
When something silently does nothing, check the input before you debug the logic.
data-rh is not decoration. It decides which tags survive.

If you want to see the output, it is running on CVBooster, a
resume builder I run. Every page announces what it is before a line of JavaScript
executes, which is all this work was ever about.

Postscript, September 2026: head only was not enough

The approach above held for the pages the prerender step knew about. It did nothing for
the ones it did not. Every URL without a prerendered file fell through to the SPA fallback,
and on Cloudflare Pages that fallback was a copy of the homepage, complete with a canonical
tag pointing at /. Google indexed that fallback for 309 URLs and filed them under
"alternate page with proper canonical", which is the polite way of saying it believed the
tag and threw the pages away.

Three changes made it hold:

Render the body too. A server-side render step in the build writes the real page content into each file, so the static markup is no longer a subset of the page but the page itself.
Send the fallback to a noindex shell, never to a homepage clone. An unknown URL should look like nothing, not like the front door.
Gate the build. A last step reads dist the way a crawler does and fails the build if any sitemap URL lacks a static file, a self-referencing canonical or 150 words of text.

Then measure from outside, every deploy: fetch every sitemap URL with a Googlebot user agent
and count the failures. The only acceptable number is zero.

We removed the LLM call and replaced it with 200 lines of template code

Mustafa Tarabya — Tue, 25 Aug 2026 12:11:32 +0000

The feature was a letter generator. Somebody fills in a few fields and gets a finished
letter of recommendation, resignation letter or notice letter, in plain text, ready to
paste into an email.

The obvious build is a prompt and a model call. We built the deterministic version instead:
a pure function, about two hundred lines, no network, no key, no tokens. I want to lay out
the reasoning, because "just call a model" is the default now and the default is not always
right.

The three reasons, in order of weight

1. The output is short and the shape is fixed.

A recommendation letter is a date block, a greeting, three or four paragraphs, a sign off
and a name. There is no structural variation to discover. Generation is valuable when the
space of good outputs is large and you cannot enumerate it. Here the space is small enough
to write down, and once you have written it down the model is doing an expensive
approximation of a switch statement.

2. It is a legal-adjacent document.

Not legal advice, but it goes into an employment record. A resignation letter that invents
a notice period, or a reference that invents a fact about a person, is a real problem for
the person who sent it. Templates cannot hallucinate. Everything specific in the output
either came from a form field or is a sentence we wrote and can be held to.

3. Zero marginal cost changes what the product can be.

This is the one that actually decided it. A model call costs money per use, and anything
that costs money per use needs an account, a rate limit and eventually a card. A pure
function costs nothing, so the tool can stay open with no signup, forever, without a
business case. That is a product decision expressed as an architecture decision, and it
only works if the code path is free.

What the code looks like

The whole engine is one exported function over one input type.

export type LetterKind = 'resignation' | 'notice' | 'recommendation';
export type LetterTone = 'formal' | 'warm' | 'brief';

export function generateLetter(input: LetterInput): string

Tone is not a prompt instruction, it is a dimension of the data. Two tiny functions carry
most of it:

function greeting(input: LetterInput, tone: LetterTone): string {
  const name = input.recipientName.trim();
  if (!name) return tone === 'warm' ? 'Hello,' : 'Dear Sir or Madam,';
  if (tone === 'warm') return `Hi ${name},`;
  return `Dear ${name},`;
}

function signOff(tone: LetterTone): string {
  if (tone === 'warm') return 'With thanks,';
  if (tone === 'brief') return 'Regards,';
  return 'Sincerely,';
}

The bodies are arrays of paragraphs, assembled conditionally. A recommendation body opens
differently depending on whether the writer told us how they know the subject:

paras.push(
  rel
    ? `I am pleased to recommend ${who} for the role of ${input.role}. ${rel}, which gave me a direct view of how they work.`
    : `I am pleased to recommend ${who} for the role of ${input.role}, based on my direct experience of working with them at ${input.company}.`,
);

That ternary is the whole trick, repeated maybe fifteen times. It is not clever. Clever was
never the requirement.

What you get for free that a model call does not give you

Determinism, which means testability. Same input, same bytes out. A snapshot test over
the full cross product of three kinds and three tones is nine assertions and runs in
milliseconds. Testing a model call means either mocking it, in which case you are testing
your mock, or asserting fuzzy properties of real output and paying for the privilege on
every CI run.

Offline and instant. No spinner, no failure state, no retry logic, no timeout, no
"the service is busy" copy to write and translate. The letter updates as the user types
because rendering it is a function call.

A real validator instead of an implicit one. With a model you tend to send whatever you
have and hope. With a template you have to decide what is required, which forces the
product question into the open:

export function missingFields(input: LetterInput): string[] {
  const missing: string[] = [];
  if (!input.senderName.trim()) missing.push('Your name');
  if (!input.company.trim()) missing.push('Company');
  if (input.kind === 'recommendation') {
    if (!input.subjectName.trim()) missing.push('Who you are recommending');
    if (!input.role.trim()) missing.push('Their role');
  } else {
    if (!input.role.trim()) missing.push('Your role');
    if (!input.lastDay.trim()) missing.push('Last working day');
  }
  return missing;
}

Note that the required set differs by kind. A recommendation has no last working day. A
resignation has no subject. A single prompt would have blurred those together and produced
something plausible for a missing field, which is worse than refusing.

Localisation is mechanical. Nine strings per tone, translated once, correct forever. The
same feature backed by a model needs the prompt tuned per language and the output checked
per language by someone who reads it.

Where the approach genuinely loses

I am not going to pretend this scales to everything.

It cannot say the specific thing. The generated paragraphs are competent and generic,
and generic is exactly the part of a reference letter that carries no weight. A hiring
manager skims "demonstrated consistent judgement" and stops at "she rewrote our billing
reconciliation and the month-end close went from four days to one".

So the engine has a highlight field, free text, dropped verbatim into the middle of the
letter. That is not a limitation we worked around, it is the correct division of labour. The
tool writes the scaffolding nobody reads. The human writes the one sentence that does the
work. A model would have written a fluent guess at that sentence, and a fluent guess about
a real person is precisely the thing you do not want in a reference.

It cannot rewrite arbitrary prose. Paste in three rambling paragraphs and ask for them
tightened, and templates have nothing to offer. That is a genuine generation task and I
would use a model for it.

Adding a kind costs a function. A new letter type means new code, not a new prompt
string. For three kinds that is fine. For thirty I would be rethinking it.

The heuristic I took away

Reach for generation when the output space is large, variable, and you cannot enumerate the
good answers. Reach for templates when the output space is small, the shape is fixed, and
being wrong is expensive.

Short formal documents sit squarely in the second category, and the industry keeps building
them with the first tool because the first tool is what everyone is holding.

The engine described here runs the
letter of recommendation template
tool on the resume builder I run. No account, no card, no model call, and the plain
text output is free to copy. It renders in whatever time a string concatenation takes,
which is the entire point.

We audited 99 resume templates for contrast. Nine rendered the candidate's name invisible.

Mustafa Tarabya — Tue, 25 Aug 2026 11:16:23 +0000

I run a resume builder with 99 templates. A user said the designs looked "basic", so we
wrote a script to measure them instead of arguing about taste. The script did not find a
taste problem. It found that nine templates rendered the candidate's name at a contrast
ratio of about 1.0 against its background.

Contrast 1.0 means the text and the background are the same colour. Two of them were
literally white on white. The name, the single most important string on the document,
was invisible.

Nobody had reported it, because nobody could see it.

Why nobody noticed

The templates are generated. A base design defines a palette, and variants override parts
of it. That is a completely normal pattern and it is where the bug lives.

The override was a shallow merge of a colors object. So a variant could set a pale
headerBackground while silently inheriting headerText from a dark base design. Both
values are individually reasonable. The combination is unreadable, and nothing in the type
system objects, because both are valid colour strings.

The failure only exists in the pair, and nothing was checking pairs.

Measuring instead of eyeballing

Contrast ratio is defined in WCAG and is fully mechanical. Relative luminance per channel:

const chan = (c) => {
  c = c / 255;
  return c <= 0.03928 ? c / 12.92 : Math.pow((c + 0.055) / 1.055, 2.4);
};

const luminance = ({ r, g, b }) =>
  0.2126 * chan(r) + 0.7152 * chan(g) + 0.0722 * chan(b);

const contrast = (a, b) => {
  const [hi, lo] = [luminance(a), luminance(b)].sort((x, y) => y - x);
  return (hi + 0.05) / (lo + 0.05);
};

The range is 1 to 21. AA wants 4.5 for body text, 3.0 for large text. Anything reporting
close to 1.0 is not "low contrast", it is the same colour, and it should be treated as a
crash rather than a style nit.

Rendering each template with sample data and walking the DOM took an afternoon. The result:
nine invisible names, and, the part I did not expect, 92 failing nodes in sidebars,
including 14 templates rendering certification names at exactly 1.00.

Sidebars were worse than main content because dark-sidebar designs are the ones most likely
to inherit a light-background text colour. The pattern that looks best is the pattern most
exposed to the bug.

Two things the audit taught me that I did not expect

The inherited claims were mostly wrong. We started from a previous audit's notes that
said 69 templates had five or more failing nodes and that one template rendered every
heading at 1.00. Measured: the worst had four, and that template's headings came in at
11.83, comfortably passing. The described root cause was a function that no longer existed
in the codebase, only a comment saying it used to.

If we had trusted the notes we would have "fixed" three things that were not broken and
missed the 92 that were. Re-measure before you refactor, especially when the notes sound
confident.

The type checker was checking nothing. While wiring the audit into CI we ran
tsc --noEmit and it passed instantly on a codebase we knew had errors. The root
tsconfig.json had "files": []. It was type checking an empty set, and had been for
a long time, exiting 0 the whole way. The real command was
tsc -p tsconfig.app.json --noEmit, which reported a 65-error backlog nobody knew about.

A green check on an empty input looks exactly like a green check on a clean codebase.

The fix that did not break the designs

The tempting fix is to force every text colour to something safe. That flattens every
design at once, and the designs were mostly fine.

Instead we resolved colours at render time and substituted only when a pair actually
fails:

function readable(fg, bg, fallbackDark, fallbackLight) {
  if (contrast(parse(fg), parse(bg)) >= 4.5) return fg;      // untouched
  return luminance(parse(bg)) > 0.5 ? fallbackDark : fallbackLight;
}

Every passing node stays byte-identical. Only the broken pairs change, and they change to
the correct end of the scale for their background. Final audit: 0 failing nodes across
99 templates, with no design regressions, because nothing that worked was touched.

The audit script stayed in the repo. A rule that is not enforced is a rule that comes back.

What I would take to any generated-design system

Shallow-merging a palette is a correctness bug waiting to happen. Validate the resulting pairs, not the individual values.
Contrast is measurable, so measure it. "Looks fine to me" is not a test, and the people who cannot read it are not in the room.
Distrust audit notes, including your own. Re-measure. Confident prose about a function that no longer exists is a real thing that happens.
Verify your verifier. Feed it a known-bad input and confirm it fails. An empty files array will pass every check you write.

The templates this came from are at CVBooster: free to
browse, no account, and now with every one of them actually legible.

Building a Minimalist Habit Tracker — Why I Stopped Using Streaks and Forest

Mustafa Tarabya — Sun, 05 Apr 2026 20:05:56 +0000

I have tried, without exaggeration, every popular habit tracker on the App Store. Streaks. Forest. Habitica. Fabulous. Productive. Way of Life. Done. I used each of them for between a week and three months. Then I stopped. Then I tried the next one. Then I built my own.

This is a post about why all of them eventually annoyed me, what I wanted instead, and the iOS app I ended up writing over about four evenings. It is called SimpleStreaks and it is about as boring as the name suggests, which is the entire point.

The pattern I kept hitting

Every habit app I tried started the same way. Clean. Promising. I would set up three habits — meditate, read, stretch — and feel vaguely virtuous about my new system. Then, reliably, one of these things would happen:

The app asked me to subscribe. Usually on day three, sometimes on day one, occasionally hidden inside the "advanced" features I actually wanted.
The gamification got in the way. A tree dies. A pet is sad. A little warrior loses XP. I am a grown adult and I do not need a guilt trip from a pixel owl because I skipped yoga on a Tuesday.
The UI got too clever. Charts inside charts. Swipe gestures for everything. Settings nested four screens deep.
The data model broke my brain. Some apps let you check a habit off multiple times per day. Some don't. Some treat skip and fail differently. Some have "rest days". By the time I understood the rules I had already lost the streak.

I do not think these are bad apps. Several of them are great. They are just not what I wanted, which is a thing that shows me seven circles, lets me tap each one once a day, and leaves me alone.

What I actually wanted

I wrote the requirements on a napkin before I opened Xcode. I still have the napkin. It says:

Home screen shows all my habits at once.
One tap marks a habit done for today.
A streak counter next to each habit. That is the only number.
No accounts. No cloud. No subscription. No ads.
Can I open it, check three things, and close it in under five seconds? That is the only UX test.

Everything that did not serve those five lines got cut.

The build

SimpleStreaks is a SwiftUI app with a Core Data backend. That is almost the entire architecture. A habit is a row with a name, an emoji, a colour, and an ordered list of completion dates. The streak is computed, not stored — walk backwards from today until you hit a gap.

The bits that were harder than expected:

Reordering. SwiftUI's List reorder works, but persisting the order to Core Data in a way that survives undo, redo, and iCloud sync took longer than the rest of the app combined. I dropped iCloud sync for v1 because of this.
"Today" logic. What counts as "today" in a timezone-changing world? I went with device-local midnight. It is not perfect but it is predictable.
Haptics. The difference between a habit tracker that feels good and one that feels sterile is one line of UIImpactFeedbackGenerator. Do not skip haptics on the check tap. It is the entire reward loop.
Widget. I wanted the widget to be the app. You should be able to tap habits on your home screen without ever opening SimpleStreaks. AppIntents made this possible in an afternoon, which felt like cheating.

Total code: about 1,800 lines of Swift. No external dependencies. No analytics SDK. No SDK anything, actually.

The things I deliberately did not build

This list was longer than the feature list.

Streak recovery. Every app has this. Pay us and your broken streak comes back. No. If the streak broke, the streak broke. Start again on Monday. It is fine.
Social feeds. The worst thing you can do to a habit tracker is turn it into a feed. The moment I have to perform my habits for strangers, they stop being habits.
XP, levels, achievements. If the streak number itself is not enough reward, no amount of confetti will save the product.
AI coaching. Several people have asked me for this. I am not ruling it out but I am ruling it out for now. The app is small on purpose.
Categories, tags, folders. If you have so many habits that you need folders, the problem is not your habit tracker.

Cutting things is the actual work of a minimalist app. Writing code is easy. Saying no to features that sound reasonable is the hard part.

Who it is for

If you used Streaks and found it a bit over-engineered, you will probably like SimpleStreaks. If you used Forest for studying and wanted something that stuck around for non-study habits, same answer. If you loved Fabulous but fell off when the subscription kicked in, this is the free version of that itch.

If you are the kind of person who likes charts, analytics, mood journals, and deep customisation — this is honestly not your app. Use Productive. Use Way of Life. Those are good tools for that job.

Where to find it

Landing page with screenshots and context: https://thedolceway.com/apps/simplestreaks
Free, no ads, no subscription: https://apps.apple.com/us/app/id6760590721?pt=126940293&ct=devto&mt=8

I would love to hear what you think, especially if you bounce off it, because "why did this not stick" is more useful feedback than "nice work". The contact is on the landing page.

Lessons for the next small app

A few things I am taking into the next build:

Write the napkin first. Five lines. If a feature does not serve a line on the napkin, it does not go in.
Ship the ugly version. I spent a full evening on the settings screen. Nobody has used the settings screen. I should have shipped without one.
Haptics and animation are 80% of "feel". The actual logic of a habit tracker is trivial. The reason people keep opening it is how the check button feels under your thumb.
Minimalism is a promise, not an aesthetic. It is fine to have lots of colours and big emojis if the app still opens, does one thing, and closes. Minimal means "no wasted steps", not "black and white".

I Built a Hydration Reminder App in a Weekend (and What I Learned)

Mustafa Tarabya — Sun, 05 Apr 2026 19:57:11 +0000

I spent a lot of last year telling myself I drank enough water. I did not. I knew this because every afternoon around 3pm my head would start to feel like someone had parked a small van on it, and the only cure was a glass of water and the quiet humiliation of realising I had drunk exactly one coffee and half a Coke Zero since breakfast.

So one Saturday I decided to build a water tracking app. Not a productivity opus. Not a subscription empire. Just something that would nag me gently, let me tap a button, and get out of the way. I called it WaterDrop and shipped it on the App Store two days later. This post is about how the weekend actually went — the parts that worked, the parts I threw away, and the stuff I wish someone had told me before I opened Xcode.

Why every water app I tried annoyed me

Before I wrote a single line of code I downloaded the top ten hydration trackers on the App Store. I wanted to see what the category looked like. Here is what I found, in roughly descending order of how much it bothered me:

Onboarding flows that asked for my height, weight, activity level, climate zone, and astrological sign before I could log a single glass.
A paywall on day three. Sometimes day one.
Gamification so aggressive that logging water felt like being yelled at by a cartoon fish.
Reminders that fired at 11pm, because apparently the app thought I should chug a litre before bed.
Widgets that were just ads for the premium tier.

I wanted the opposite of all of this. Open app. Tap once. Done. No login. No fish.

The architecture, such as it is

WaterDrop is embarrassingly simple and I am not apologising for it.

SwiftUI for everything. No UIKit bridges.
A single @AppStorage key for today's count. A small Core Data store for history, because I wanted streaks.
Local notifications scheduled via UNUserNotificationCenter, no server.
WidgetKit for the home screen widget. AppIntents so you can log a glass from Siri or a shortcut.
Zero network calls. Zero analytics SDKs. Zero accounts.

The whole thing is maybe 1,400 lines of Swift. The hardest part was not the code. The hardest part was resisting the urge to add things.

The features I cut

Here is a partial list of things I designed, half-built, or sketched and then deleted:

A "hydration score" that factored in caffeine and alcohol. Fun, but it needed a whole second data model and nobody asked for it.
Social sharing of streaks. Why would you share this with anyone. Cut.
Apple Health two-way sync. I still want this but doing it properly takes more than a weekend.
A plant that grows as you drink. Cute. Not me. Cut.
Custom drink types (tea, sparkling, etc). I may add this later. For launch it was friction.

Every time I cut something the app felt lighter. That is the actual lesson of the weekend.

Reminder logic is harder than it looks

The part I underestimated was reminders. You would think "ping the user every 90 minutes during waking hours" is a three-line function. It is not. You have to think about:

Quiet hours. Nobody wants a 2am water ping.
The user's actual sleep schedule, which you do not know.
Not reminding them if they just logged a glass (otherwise the app feels robotic).
Weekends vs weekdays.
What happens after the device restarts and your pending notifications were reset.

I ended up with a simple rule: the user picks a start hour and end hour. Inside that window, reminders fire every N hours, and any reminder within 30 minutes of a logged glass gets cancelled. That was version one. Turns out version one was also version final, because it just works.

Shipping on a Sunday night

I hit upload in Xcode around 9pm Sunday. Apple approved it in about 18 hours, which is faster than I expected for a brand new developer account doing anything health-adjacent. The only feedback from review was a request to clarify that the app does not replace medical advice, which is fair.

If you want to see what I ended up with, it is here:

Landing page with screenshots: https://thedolceway.com/apps/waterdrop
Free on the App Store: https://apps.apple.com/us/app/id6760830381?pt=126940293&ct=devto&mt=8

It is free, there is no subscription, and there is no account. If you try it and something feels wrong I would genuinely like to hear about it.

What I would do differently

A few honest regrets.

Screenshots. I rushed them. App Store screenshots are the single biggest conversion lever for a free app and I spent maybe 40 minutes on them. I am redoing them this week.
Keyword research. I picked "hydration tracker" as my main keyword on vibes. I should have used an actual ASO tool. I am fixing this in the next metadata update.
Icon iteration. I made one icon and shipped it. It is fine. It is not memorable. Icons deserve their own afternoon.
Not timing the build. I wish I had logged how long each part took. Would have been great data for the next one.

The point of the weekend

I have shipped maybe a dozen things this year, most of which nobody will ever use, and a few I genuinely like. WaterDrop is in the second category because it solved an actual problem for me personally. I stopped getting the afternoon headache about a week after I started using it, which is either the app working or a placebo, and honestly I do not care which.

If you are sitting on a small idea and telling yourself it is too small to ship — it is not. Two days. One screen. One problem you personally have. That is the whole formula. Go build the thing.

And drink some water while you are at it.

How AI Resume Builders Are Changing Job Applications in 2026

Mustafa Tarabya — Thu, 26 Mar 2026 11:53:37 +0000

The job market has always rewarded people who know how to present themselves. In 2026, that presentation is increasingly mediated by AI — on both sides of the hiring table.

Recruiters are using AI to screen applications. So job seekers are using AI to write them. What started as a niche productivity hack has become table stakes for anyone serious about their search.

The Numbers Are Hard to Ignore

Recent hiring data shows that over 75% of resumes submitted to large employers are filtered by applicant tracking systems before a human ever sees them. These systems scan for keywords, formatting compliance, and relevance signals. A beautifully designed resume that fails ATS parsing is invisible.

AI-powered resume tools have responded to this shift directly. The best ones don't just help you write — they help you write in a way that survives automated screening and reads well to a human afterward.

What AI Resume Tools Are Actually Good At

Rewriting weak bullet points. This is where AI genuinely earns its keep. "Managed a team" becomes "Led a cross-functional team of 8 engineers to deliver a platform migration 3 weeks ahead of schedule." The AI pulls on pattern recognition trained across millions of successful resumes to elevate vague descriptions into quantified accomplishments.

Keyword optimization. A good ai resume builder will analyze a job posting and suggest which terms belong in your resume. This isn't gaming the system — it's speaking the language that both ATS and recruiters are scanning for.

Reducing blank-page paralysis. Many people know what they've done but struggle to articulate it in resume format. AI suggestions act as a starting draft that you refine, rather than a blank document that stares back at you.

Consistent formatting at speed. Tailoring a resume to each application used to mean an hour of reformatting per job. AI-powered tools can restructure and reorder sections in seconds.

What They're Not Good At

AI resume tools are pattern-matching engines, not career coaches. They don't know your actual impact, the real context of your achievements, or what makes you different. Output always needs a human editorial pass.

They're also not magic for career changers. If you're pivoting industries, the AI will default to your existing experience framing. You'll need to guide it more deliberately toward how your transferable skills map to the new domain.

The Democratization Angle

Perhaps the most important shift is accessibility. Professional resume writing services charge $200-600 per resume. That's a real barrier for recent graduates, career returners, or anyone in financial transition — precisely the people who most need help.

AI-powered resume tools like CVBooster have changed that equation. The same quality of structured, keyword-optimized, professionally formatted resume that used to require either expertise or a budget is now available for free, instantly, without a subscription.

The Hiring Side Is Adapting Too

It's worth acknowledging the counter-movement: some hiring managers are now flagging AI-generated resumes as a negative signal, particularly for roles requiring strong written communication. The lesson here is balance — use AI to structure and optimize, but make sure your voice and specific context come through in the final version.

What's Next

The trajectory is clear. Resume screening will become more AI-to-AI in nature — automated systems on both sides, with humans reviewing only shortlisted candidates. The job seekers who understand this dynamic and use AI tools intelligently will have a structural advantage over those who don't.

The tools are good now. They'll be better in six months. The question isn't whether to use them — it's whether you're using them well.

The Best Free Resume Builders That Don't Charge You After Download

Mustafa Tarabya — Thu, 26 Mar 2026 09:17:45 +0000

There's a frustrating pattern in the resume builder industry. You spend 45 minutes filling in your work history, choosing a template, tweaking the layout — and then you hit download. Suddenly a paywall appears. Your resume is being held hostage.

This is not a coincidence. It's a business model. Get users invested before revealing the price. After 45 minutes of work, many people just pay rather than start over.

Let's talk about how to avoid this — and which tools are actually free.

The "Freemium Trap" in Resume Builders

Most resume builders operate on a freemium model where the core feature — exporting your resume — is locked behind a subscription. The free tier exists to create friction and investment, not to deliver value.

Here's what "free" usually means in this industry:

Resume.io: Free to build, $2.95/week to download in a usable format
Zety: Free to build, watermark on PDF unless you pay ~$5.99/month
Novoresume: Free plan limited to one resume with restricted templates; download requires premium
VisualCV: Free plan creates a web resume, but PDF export is paid
Canva: Genuinely free for many templates, but resume-specific features are limited and formatting can be inconsistent for ATS systems

The key test: can you download a clean, watermark-free PDF without entering payment details? Most tools fail this test.

Tools That Are Genuinely Free

CVBooster is the standout here. The free resume builder gives you access to professional templates, an AI-assisted editor, and clean PDF download — no signup wall, no credit card, no watermark. You can build and export a complete resume in under 20 minutes at zero cost.

This matters more than it might seem. Job hunting is already expensive — LinkedIn Premium, Indeed sponsored applications, professional wardrobe for interviews. Paying $20/month for a resume builder adds up fast, especially when you might be between jobs.

Google Docs (with a resume template) is another genuinely free option if you know how to format documents. The trade-off is manual labor — no AI suggestions, no ATS optimization hints, just you and a word processor.

LibreOffice templates fall in the same category: free but manual.

For most job seekers who want professional output without the manual work, the free resume builder at CVBooster is the strongest option I've found.

What to Look For in a Free Resume Builder

When evaluating any tool, check these before investing your time:

Download test first: Before filling in your details, check whether PDF download requires payment. Many tools advertise this in their pricing page — read it before you start.
ATS compatibility: Does the template use single-column, clean formatting? Multi-column layouts often fail ATS parsing, which can disqualify your application before a human reads it.
No watermarks: A resume with a service watermark looks unprofessional. Confirm the export is clean.
No forced account creation: Some tools won't let you access your resume later without creating an account, which becomes a vector for upsell emails and locked features.
Template variety: You may want to tweak templates for different industries. A tool with only 2-3 free templates limits your options.

The Broader Point

The resume builder market is built on a pain point — people genuinely struggle to present themselves on paper — and many companies exploit that vulnerability with bait-and-switch pricing. Knowing this going in puts you in a much stronger position.

You don't need to pay to get a great resume. You need the right tool and 20 focused minutes. Start with something genuinely free, invest your energy in the content, and save your money for the parts of your job search that actually require spending it.

I Tested 5 AI Resume Builders — Here's What Actually Works

Mustafa Tarabya — Thu, 26 Mar 2026 09:16:09 +0000

I spent a week testing every major AI resume builder on the market. Not quick demos — actual resumes, submitted to real jobs, run through ATS scanners. Here is what I found.

The Problem With Most AI Resume Builders

Most tools in this space do the same thing: you paste your info, the AI rewrites your bullets to sound fancier, and you download a PDF. The problem is that "fancier" does not mean "optimized." A resume that sounds impressive to a human can still score poorly in an Applicant Tracking System if it lacks the right keywords.

The best AI resume builder tools do more than rewrite — they analyze the job description, match keywords, and ensure formatting survives ATS parsing.

What I Tested

I evaluated five tools on these criteria: ATS compatibility, template quality, keyword matching, and whether the "free" tier is actually usable.

1. Zety — Slick interface, good templates. But the free tier is bait — you cannot download without paying. ATS optimization is minimal. The AI suggestions are generic.

2. Resume.io — Clean templates, fast editor. Same paywall problem. No keyword matching against job descriptions. The AI just rephrases your existing text.

3. Teal — Better approach. Matches your resume against a job description and highlights missing keywords. Free tier is limited to basic features. Good for keyword gaps but the template selection is small.

4. Rezi — Focused on ATS optimization. Decent keyword analysis. Interface feels dated. The AI rewriting is solid but template variety is lacking.

5. CVBooster — This one surprised me. 160+ templates including 17 completely free ones. No account required. The AI resume builder matches your resume against job descriptions, suggests missing keywords, rewrites bullets with measurable impact, and generates cover letters. You can download a polished PDF without creating an account or hitting a paywall.

The Verdict

Most AI resume builders are fancy text editors with a paywall at the end. The ones that actually help you get hired do three things: keyword matching against the specific job, ATS-friendly formatting, and honest pricing.

If you want to try the one that scored highest in my testing, check out CVBooster's AI resume builder — it is genuinely free to start and does not trap you at the download step.

The resume builder market is crowded but most of the crowd is selling the same thing. Find the tool that actually optimizes for ATS, not just for looking good on screen.

5 Forest App Alternatives That Actually Help You Focus in 2026

Mustafa Tarabya — Thu, 26 Mar 2026 07:27:56 +0000

If you've ever tried to cut down on phone distractions, you've probably come across Forest — the app that grows a virtual tree while you stay off your phone. It's charming, and it works for a lot of people. But it's not for everyone.

The good news is that there are solid forest app alternatives out there. Here are five worth trying in 2026.

1. Flora

Flora is the closest spiritual sibling to Forest. It uses the same tree-growing mechanic but adds a social layer — you can plant trees with friends and keep each other accountable. If you break focus, the tree dies for everyone. Flora also lets you donate to real tree-planting initiatives.

Best for: People who want accountability with friends or coworkers.

2. Freedom

Freedom takes a more aggressive approach. Rather than gamifying focus, it blocks distracting websites and apps across all your devices simultaneously. One session locks you out on your Mac, iPhone, and iPad at the same time. It's less cute than Forest, but far more effective for people who need hard barriers.

Best for: Remote workers who need serious distraction blocking across multiple devices.

3. Be Focused (Pomodoro Timer)

Be Focused is a clean Pomodoro timer for Apple devices. No gamification — just structured 25-minute work blocks with short breaks. It tracks how many Pomodoros you complete each day. Sometimes the most effective tool is the simplest one.

Best for: Minimalists who prefer the Pomodoro technique.

4. Focusmate

Focusmate flips the model entirely. Instead of a virtual tree, you get a real human. You book a video session with a stranger, state your goal, work silently, and check in at the end. The social presence effect is one of the strongest focus hacks known to productivity researchers.

Best for: People who struggle with isolation while working from home.

5. Session

Session is a premium focus timer for Mac that integrates with your calendar and task manager. It shows your tasks alongside your timer, lets you block apps, and gives detailed analytics on your work patterns. If you want a forest app alternative that feels polished on macOS, Session is the one to beat.

Best for: Mac users who want deep workflow integration.

Which One Should You Pick?

The right app depends on what kind of friction you need. Social accountability? Flora or Focusmate. Hard blocks? Freedom. Simplicity? Be Focused or Session.

For a deeper comparison with pros, cons, and pricing for each forest app alternative, check out the full breakdown at The Dolce Way.

Finding the right alternative is about matching the tool to how your brain actually works — not just downloading whatever has the best App Store rating.

5 Ways AI is Changing Small Business Operations in 2026

Mustafa Tarabya — Thu, 26 Mar 2026 07:26:35 +0000

AI is no longer a luxury reserved for enterprise companies. In 2026, small businesses are using AI tools to automate repetitive tasks, make smarter decisions, and compete with organizations ten times their size.

Here are five ways this is actually playing out.

1. Customer Support That Never Sleeps

AI chatbots have moved past the "press 1 for billing" era. Modern AI support agents can understand context, pull from knowledge bases, and resolve issues without human intervention. For a small business owner who cannot afford a 24/7 support team, this is transformative.

The key shift is that these tools now integrate with existing workflows. They connect to your CRM, read your documentation, and handle the first line of contact — escalating to humans only when necessary.

2. Automated Bookkeeping and Financial Forecasting

AI-powered accounting tools can categorize expenses, flag anomalies, and generate cash flow projections based on historical patterns. Small business owners spend an average of five hours per week on bookkeeping. AI can cut that to thirty minutes.

The real value is not in data entry — it is in the forecasting. Knowing next month's likely revenue before it arrives changes how you plan inventory, hiring, and marketing spend.

3. Content Creation and Marketing Automation

Small businesses need content but rarely have dedicated marketing teams. AI writing assistants can draft social media posts, email campaigns, and blog outlines in seconds. The output still needs a human eye, but the first draft is no longer the bottleneck.

Marketing automation platforms now use AI to determine optimal send times, segment audiences, and personalize messaging at a level that was previously only possible for companies with data science teams.

4. Smart Inventory and Supply Chain Management

For product-based businesses, AI demand forecasting prevents both overstock and stockouts. These systems analyze seasonal trends, competitor pricing, and historical sales data to recommend order quantities.

The difference from traditional inventory management is precision. Instead of ordering based on gut feeling and last year's numbers, you are ordering based on a model that accounts for dozens of variables simultaneously.

5. AI-Powered Business Intelligence

Dashboards that just show numbers are table stakes. AI business intelligence tools explain why the numbers changed and what to do about it. They surface patterns that a human reviewing spreadsheets would miss.

Platforms like Vecta AI are building exactly this kind of intelligence layer for small businesses — turning raw data into actionable recommendations without requiring a data analyst on staff.

The Bottom Line

The businesses adopting AI in 2026 are not doing it because it is trendy. They are doing it because the tools are finally good enough, cheap enough, and simple enough to deliver real ROI at small scale.

The gap between AI-enabled small businesses and those still running on spreadsheets and manual processes is widening every quarter. The time to start is not next year.

Learn more about AI solutions for business at vectaai.com.