Skip to main content

Create Software from a Goal

Worka starts with a goal. The quality of that goal affects the quality of the workspace that follows.

This does not mean you need to write a perfect prompt. It means you need to make the job concrete enough that Worka can tell what software should exist.

What to include in a good request​

A good request usually answers five questions:

  1. what is the workspace for
  2. who will use it
  3. which systems, sources, or services matter
  4. what the main view should help people do
  5. what kinds of actions or outcomes matter most

You do not need to answer them in that exact order. You do need to cover them clearly enough that another person could understand the job.

The easiest formula​

If you are unsure where to start, use this pattern:

Build a workspace for who that helps them do what, using which systems or sources, with a main view for which job.

Examples:

  • Build a workspace for my family that keeps Google Calendar, WhatsApp reminders, and weekly plans in one place, with a main view that shows what we need to do this week.
  • Build a workspace for my marketing team that combines Google Ads, Google Sheets, and approvals, with a main view for campaign performance and next actions.
  • Build a library app using openlibrary.org that lets people browse categories, open books, and read details.

What not to over-specify​

You do not need to tell Worka:

  • how many views to create
  • what pack names to use
  • what the internal workflow graph should be
  • what tool calls to invent
  • what storage model or runtime design to choose

Those are Worka's job.

If you try to specify too much too early, you usually make the request harder to review later because it becomes full of assumptions that may not actually fit the workspace.

When to name a service explicitly​

Name the exact service or data source when it is important to the workspace.

Good examples:

  • “use openlibrary.org”
  • “connect our Google Ads account and our Google Sheets reporting sheet”
  • “this should work from WhatsApp messages and our Google Calendar”

That helps Worka avoid guessing the wrong source system.

Weak and strong requests​

Weak:

Help with family stuff.

This is too vague. It does not tell Worka whether you need schedules, messages, reminders, meal planning, travel coordination, or something else.

Stronger:

Build a family coordination workspace that combines Google Calendar, school reminders from WhatsApp, and weekly plans into one place, with a main view that makes it obvious what we need to do this week.

Weak:

Build some software for the sales team.

Stronger:

Build a workspace for our sales team that combines lead status, follow-up tasks, and handoff approvals, using Salesforce and our shared Google Sheet, with a main view that shows which deals need attention today.

What happens after you ask​

Once you submit the goal, Worka uses it to work out:

  • what views the workspace needs
  • what AI team members and workflows may be useful
  • what services and packs are required
  • what approvals or connections might be needed

This is why the goal matters so much. You are not feeding a chatbot. You are briefing a system that is about to shape software around the request.

A quick self-check​

Before you submit, ask yourself:

  • could another person understand what the workspace is for
  • is it clear who the main users are
  • is it clear what the main view should make easy
  • have I named the important systems precisely if they matter

If yes, Worka usually has enough to begin well.