<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Cyrus</title>
    <description>The latest articles on DEV Community by Cyrus (@cyrus_470f9201d07f2e01484).</description>
    <link>https://dev.to/cyrus_470f9201d07f2e01484</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4222043%2F2da0305b-e3f1-4ae3-98a6-eedc65da753b.png</url>
      <title>DEV Community: Cyrus</title>
      <link>https://dev.to/cyrus_470f9201d07f2e01484</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/cyrus_470f9201d07f2e01484"/>
    <language>en</language>
    <item>
      <title>Dashboards Built for a Demo and Then Quietly Left to Rot</title>
      <dc:creator>Cyrus</dc:creator>
      <pubDate>Wed, 04 Nov 2026 09:25:03 +0000</pubDate>
      <link>https://dev.to/cyrus_470f9201d07f2e01484/dashboards-built-for-a-demo-and-then-quietly-left-to-rot-8pa</link>
      <guid>https://dev.to/cyrus_470f9201d07f2e01484/dashboards-built-for-a-demo-and-then-quietly-left-to-rot-8pa</guid>
      <description>&lt;p&gt;I’ve sat in enough tool evaluations to recognise the demo screen. Large numbers, a map with dots on it, a gauge that is some shade of green, and a row of charts that look impressive on a projector and answer nothing anybody asked the following week.&lt;/p&gt;

&lt;p&gt;I’m not against a good dashboard. I’ve built a few of these myself, and I understand the pressure. You need something to show a room, and a well-designed screen communicates faster than a paragraph.&lt;/p&gt;

&lt;p&gt;The trouble starts when the demo screen becomes the permanent screen. Nobody retires it, nobody maintains it, and six months later it is still the first thing that loads, showing a number nobody can explain.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fhdrqq68ou7zsrsnu060r.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fhdrqq68ou7zsrsnu060r.png" alt=" " width="800" height="556"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;h2&gt;
  
  
  What Day-to-Day Life With These Looks Like
&lt;/h2&gt;

&lt;p&gt;The first symptom I notice is that the metrics do not match anything in the reports people actually use. Two tools both claim a count of protected endpoints, and the numbers differ. Nobody can say why without a dig through field mappings.&lt;/p&gt;

&lt;p&gt;Then there is the question of freshness. Some tiles update hourly, some are static images in the page, and one has been showing the same figure since a migration. I’ve watched a team make a decision on a number that was three weeks old because nothing on the screen indicated its age.&lt;/p&gt;

&lt;p&gt;Filters tend to be the next problem. The default view covers everything, which is fine for a demo and useless for a Tuesday. Nobody bothered to save the three filtered views that would have made it genuinely helpful.&lt;/p&gt;

&lt;p&gt;And then maintenance quietly stops. The data source gets renamed, a connector breaks, the tile goes blank or freezes at its last known value, and it takes a while for anyone to notice because nobody was relying on it.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fwdzw70ydd9xosyreo6zg.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fwdzw70ydd9xosyreo6zg.png" alt=" " width="800" height="600"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;h2&gt;
  
  
  Why Demo Screens End Up Permanent
&lt;/h2&gt;

&lt;p&gt;I think it comes down to who is in the room. A dashboard built during an evaluation is answerable to the people evaluating, and their questions are broad. Are we covered, what is the trend, how does this look. Those are reasonable but they are not operational questions.&lt;/p&gt;

&lt;p&gt;Once the tool is bought, the people who would ask operational questions are busy elsewhere. The screen that satisfied procurement stays, because replacing it is work that has no deadline and no owner.&lt;/p&gt;

&lt;p&gt;There is also something about large numbers. A count in the tens of thousands feels reassuring in a meeting, even when nobody has defined what is being counted. I’ve yet to see a room ask whether the denominator was right.&lt;/p&gt;

&lt;p&gt;People tend to over-trust anything that looks designed. Clean layout, consistent colours, a logo in the corner. It reads as authoritative, so nobody opens the query behind it.&lt;/p&gt;

&lt;h2&gt;
  
  
  What I’ve Seen Teams Try
&lt;/h2&gt;

&lt;p&gt;I’ve also seen unified platforms such as Ping64 used to cut down the overhead of juggling many separate security tools.&lt;/p&gt;

&lt;p&gt;For the dashboards, the thing I’ve seen work is starting from a decision rather than a screen. What will you do differently if this number moves. If the answer is nothing, the tile probably does not need to exist.&lt;/p&gt;

&lt;p&gt;Some teams keep a small number of working views and delete the rest. Three or four screens, each tied to a recurring task, tend to be used. A wall of twenty tends to be admired once and ignored afterwards.&lt;/p&gt;

&lt;p&gt;A few places added a last-updated timestamp and a source name to every tile. It is unglamorous and it settles a lot of arguments quickly.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fc4ndrku7ph2ady21p30g.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fc4ndrku7ph2ady21p30g.png" alt=" " width="800" height="600"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;h2&gt;
  
  
  Small Practical Suggestions
&lt;/h2&gt;

&lt;p&gt;Write the question above the chart, not just the title. It keeps everyone honest about intent.&lt;/p&gt;

&lt;p&gt;Show the refresh time on every panel. Stale data that announces itself is much less dangerous.&lt;/p&gt;

&lt;p&gt;Name the source system and the query owner somewhere visible.&lt;/p&gt;

&lt;p&gt;Start with three views that map to three real tasks. Add more only when asked.&lt;/p&gt;

&lt;p&gt;Check the denominator before trusting a percentage. This is where most surprises live.&lt;/p&gt;

&lt;p&gt;Delete one unused screen each quarter. Nobody has ever missed one in my experience.&lt;/p&gt;

&lt;p&gt;Keep the demo view separate from the working views, and label it as such.&lt;/p&gt;

&lt;p&gt;Ask a new colleague to interpret a tile in their first week. Their confusion is useful feedback.&lt;/p&gt;

&lt;h2&gt;
  
  
  Closing
&lt;/h2&gt;

&lt;p&gt;I don’t think demo dashboards are a mistake. They serve a purpose at a particular moment, and a clear screen in a meeting is genuinely worth having. The problem is only when the temporary artefact becomes the operating view and nobody notices the swap. In my experience, a small number of plain screens tied to real decisions gets used far more than a wall of polished ones. Fewer tiles, clearer questions, and a visible timestamp will take you a long way.&lt;/p&gt;

&lt;h2&gt;
  
  
  References
&lt;/h2&gt;

&lt;ul&gt;
&lt;li&gt;NIST SP 800-53 Rev. 5, Security and Privacy Controls: &lt;a href="https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final" rel="noopener noreferrer"&gt;https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final&lt;/a&gt;
&lt;/li&gt;
&lt;li&gt;NIST SP 800-137, Information Security Continuous Monitoring: &lt;a href="https://csrc.nist.gov/pubs/sp/800/137/final" rel="noopener noreferrer"&gt;https://csrc.nist.gov/pubs/sp/800/137/final&lt;/a&gt;
&lt;/li&gt;
&lt;li&gt;MITRE ATT&amp;amp;CK, Enterprise framework: &lt;a href="https://attack.mitre.org/" rel="noopener noreferrer"&gt;https://attack.mitre.org/&lt;/a&gt;
&lt;/li&gt;
&lt;li&gt;CISA, Cybersecurity guidance and resources: &lt;a href="https://www.cisa.gov/" rel="noopener noreferrer"&gt;https://www.cisa.gov/&lt;/a&gt;
&lt;/li&gt;
&lt;/ul&gt;

</description>
      <category>management</category>
      <category>product</category>
      <category>softwareengineering</category>
    </item>
  </channel>
</rss>
