9
5 Comments

How much time and effort do you spend in admin tooling?

Hey IHers,

So while building ProsperCircle.org, I've spend almost 20 - 25% of my time working on admin tools.
E.g., Cron jobs to make sure the job is active, custom dashboards to track various aspects of growth, dynamic sitemap generator based on database updates, etc.

I'm curious how much time do you spend on admin tooling for your product?

  1. 3

    I've tried to spend a lot less time on this sort of thing as of late and just offload it on other apps, usually on their free tiers if possible. I wouldn't say I've ever spent quite as much as 20-25% of my time on admin tools, probably more like 10%.

    You may know about Retool, but just in case, I've used it to put together quick dashboards just to keep tabs on things and it makes it a lot easier than having to code my own.

    1. 1

      Thanks for sharing Retool. Looks promising.

  2. 1

    I ❤️ admin tooling. I hold the same opinion for both projects at work and hobby projects. Once a project moves to production, it become crucial to have such tooling. Might not seem necessary at first, but the value of admin tooling is only noticeable when things go wrong.

    Here are the few themes I've noticed for building admin tooling:

    1. Frequent requests:

      • Features that are not exposed to the user in the product for some reason.
      • This usually grows after observing a pattern of requests from the customers/team.
    2. Feature monitoring:

      • Simplest example is a Feature-ABC supposed to do X. If X can go wrong, then periodically run database queries to detect issues and send alert emails.
      • I call these "Patrol checks" (not sure if there is a commonly used name for this).
      • I began recommending these alerts at work because we depend on a lot of third-party APIs as a nature of business. So it is useful to know when things don't run as expected.
    3. Demo setup: After moving to the Product team at work, this is new theme of tools that I've found useful to have.

      • Features we build are going to be demoed (both sales and internal demos). So I've begun including "demoability" as a part of my feature specifications.
      • I've gotten the team to build internal tooling that helps setup demo data on an account with a few clicks.
      • In just the last month, this has help the team identify quite a few bugs during testing that they never would have never found without these tools.

    At work, for my own use, I maintain a Notion page with SQL queries that I usually run. I have a reputation for writing really LONG 1-page queries to get my work done - I'm fine with waiting 10min if that's what it takes to run them 🤣

    There's a fine line between necessary tooling and overkill, that which only the people involved in the project can recognise. Just like products, it is often better to build the necessary minimum and build the rest over time.

    1. 1

      @HashNuke - I enjoy admin tooling also.

      In a weird way, just creating the tooling helps me understand the business a bit better.

  3. 1

    Nothing really, we usually find a way to break down what we are using into separate pieces which match our infra or find other tools. For instance for Authress we use AWS cloudwatch rules to trigger lambda functions, and then the free tier of SumoLogic to track errors and high level reporting. It also supports alert emails.

Trending on Indie Hackers
I sold Pingr. Lessons learned. 40 comments Speed is the killer feature 13 comments Nailing Quora Marketing - 5k weekly views with a few minutes of work 10 comments Are you ever embarrassed at the product/service you've built? 7 comments Twitter is testing a way for indie hackers to sell products through tweets 5 comments Rosie Sherry on building communities 3 comments