Utility applications start with daily tasks
How do you make a mini app as polished as one you could buy? A hint lies in new functionality from LLMs to create tasks. Read: "Everything Starts Out Looking Like a Toy" #234

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: pixel art that turns your photo into a buildable masterpiece. Creating bespoke LEGO kits fits the general idea we’re thinking about today: application creation for a small audience that feels mass-produced. Edition 234 of this newsletter is here - it’s January 21, 2025.
Thanks for reading! Let me know if there’s a topic you’d like me to cover.
The Big Idea
A short long-form essay about data things
⚙️ Utility applications start with daily tasks
This week, OpenAI added a beta feature for ChatGPT that enables users to create scheduled tasks. “Asking ChatGPT to do things in the future” is more than a call to action: it’s a potential application primitive.
By “primitive”, I mean that identifying a set of steps and scheduling when it will run is the building block of a bespoke application. Running that application with ChatGPT as the scheduler sounds like a custom-made set of applications to solve everyday tasks. (If you don’t like ChatGPT, consider that similar technology like Pipedream or Zapier offers similar functionality).
For example, if “summarize news every week” becomes:
find a list of companies contained in this spreadsheet location
for each company, run a templated search query to identify links with these topics (a, b, c)
compare against the spreadsheet or database containing past links about topic a, b, c for a company
summarize into an email or Slack alert indicating whether this is a new article on topic a, b, c
You’ve created a competitive intelligence application. A simple one, but one that can take structured input and return structured output. That means you could take the output from this step and send it somewhere else, say to a record in a CRM system corresponding to that company. Your app could also trigger a threshold alert letting someone know they need to take action.
Identifying a frequent task, knowing where to go (and on what schedule) to check if the task is complete, and understanding how to complete the task are the components to create a “mini-app” that enables ops folks to bridge the gap between “apps that need developers” and “go do that task and report that it’s done.”
What’s different from this concept of an app and a traditional “Internal Application” is that more of the work is abstracted away into a canvas where the internal employee can do more while having the guardrails we expect of an application.
We do want team members to be creative in how they add automation to speed up and improve the quality of their tasks; we don’t want to introduce new problems that are different from the risks we have already.
What are the components of a mini-app?
Assuming these “mini-apps” are a good idea, they have a few basic capabilities to be able to run.
NOTE: we’re also assuming in this example that this person is authorizing access using a service account or their own Google Workspace account (or similar), which sets a basic level of security. We’re also assuming a pretty verbose log to understand what happened.
A mini app needs as part of its manifest or description:
What needs to get done - why are we doing this in the first place? An app ought to be able to tell you why it exists. Is this app for a single person to help get their work done or is it a process run by all the members of a group?
Whether this step is synchronous or asynchronous - does it run after other steps or in parallel to those steps?
What information does it need to start – a data structure indicating the necessary fields and value options (if values are picklist) to proceed. A self-documenting app provides the equivalent of an API to call that building block.
What information is returned – a similar example showing the payload returned on step completion.
How will we know when it’s done – is there a standard way to show completion, and is there a set of common error states?
In the ChatGPT example above, moving from “tasks” to Mini-apps might look like the following diagram. The bigger picture is that this pattern might span only a few blocks or eventually by a series of multi-purpose apps.
What’s missing from this idea?
Ok, so this might work for a single person stringing together tasks. How could you improve it to work for more than one person or for more complicated workflows? One key element you’d want to add is source control/version control.
A straightforward way to document these workflows? Some sort of data specification language or JSON or YAML would do the trick, and JSON would be the most flexible and parsable by other applications. Writing out the workflow steps in JSON would enable you to use version control like Github to store the current state of the flow.
What’s the takeaway? Expanding a scheduled task to a repeatable process that interacts with other blocks of code requires common agreement and a pattern of data observability and documentation. If this works, we could be headed to a world where many more internal apps get built on the fly (and it also implies a greater need for internal APIs that guard against inexperienced developers).
Links for Reading and Sharing
These are links that caught my 👀
1/ I hope you never see this sign - Apparently, there are designs for signs in areas contaminated by radioactivity.
2/ Getting better at data - Channeling the theories of W. Edwards Deming is an excellent way to codify steps to manage the data in your environment effectively. Perhaps unsurprisingly, the process of managing data people, process, and tools depends on clear communication, identifying, and removing obstacles. (And repeating when you find a new problem.)
3/ How to fail - Nir Eyal writes about how to become more resilient when you fail. Why is this important? Because it’s guaranteed that you’ll experience failure. Building up your ability to respond positively to that failure is one of the most important things you’ll do.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon