On this page
Our editorial standards at a glance
A named author
Every piece has one author, Roger Grekos or Thanos Gkanas, who is responsible for what it says.
Primary sources
Claims about products, laws, vulnerabilities and dates link to the vendor, standards body or regulator that published them.
Honest dates
The published date never moves. The updated date moves only when the content changes.
Visible corrections
When we fix a factual error, the change log on the piece says what changed and when.
Who writes and reviews
Two people write everything we publish. Roger Grekos writes the product guides on validation, discovery, UX, pricing and roadmaps. Thanos Gkanas writes the engineering guides, the alerts and updates, and the startup stack tracker.
The other founder can review a piece. Thanos checks the technical claims in product pieces, shown as Technically reviewed by. Roger checks the product and user side of engineering pieces, shown as Product reviewed by. The reviewer line, with its date, appears only once that review has happened, and nobody reviews their own piece.
Roger Grekos
Co-Founder, Product, Project & Scale
Co-Founder. Leads product, projects and scale, with 12+ years in product, from X, the moonshot factory, to Find.co.
Thanos Gkanas
Co-Founder & Head of Engineering
Co-Founder. Leads engineering, with 20+ years building systems, from SAP and Pitney Bowes to rescues and re-architecture.
How a piece is made
- 01
Brief
We pick a question founders search for or ask us about, and write down what the piece must answer and for whom.
- 02
Sources
We collect the primary sources first: documentation, changelogs, advisories, standards and official guidance, each with the date we checked it.
- 03
Write
The author writes in plain language, with the answer near the top and the reasoning after it.
- 04
Review
The author checks every claim against its source. When the other founder reviews the piece, their name and the review date are added.
- 05
Publish
Before a piece goes live, automated checks look at its links, dates, headings, sources and wording.
- 06
Update
We revisit a piece when a source changes. Alerts are watched until their deadline passes, and the tracker is re-checked on a schedule.
How we choose sources
We link to the organization that owns the fact. For software, that means the vendor's documentation, release notes and changelogs. For security, it means advisories and databases such as the National Vulnerability Database, GitHub security advisories and CISA. For standards and law, it means bodies such as OWASP, NIST, the W3C and the regulator that wrote the rule.
Each source in a piece shows the date we last checked it. We do not cite other consultancies or agencies as evidence, and we do not cite a source we could not open and read ourselves.
What our dates mean
- Published is the day a piece first went live. It never changes.
- Updated is the last day the content changed in a way a reader would notice, such as a new section, a corrected fact or a new source. Adding an internal link does not move it.
- Checked on a source is the day we last confirmed that the source still says what we cite it for.
Dates are shown in Toronto time. Our Startup security alerts and updates also show the key dates of the event itself, such as a deadline or an effective date, taken from the source.
How we use AI tools
We use AI tools in our writing process: to search and summarize documentation, to suggest an outline, to draft passages and to check our wording against these standards. We do not use them to invent facts, quotes, figures or sources.
A person checks every factual claim against its primary source before a piece is published, and the named author is responsible for the result. If a tool got something wrong and we missed it, that is our error, and we correct it as described below.
DISCLOSURE
What we disclose
BrainStormers sells the engineering and product services our guides discuss, and most pieces link to the service they relate to. We say so here so you can weigh our advice with that in mind.
We do not take payment to mention a product, and our articles carry no affiliate links. When a piece covers a company we partner with or do client work for, the piece says so.
Corrections policy
If you think something we published is wrong, out of date or missing a source, write to hello@brco.dev with the page address and what you think needs to change. A link to the source that shows the problem helps most.
The author checks the report against the source. If we got it wrong, we fix the piece, move its updated date and add a line to its change log that says what changed. We do not quietly rewrite a claim, and we do not delete a published piece because it contained an error. If a piece is no longer accurate as a whole, we say so at the top, or we replace it and send its old address to the new one.