Getting started with Mayson means writing a plain-language description of the app you want and letting it generate a working version, backend included, in the same pass. There's no separate stage for setting up a database or writing authentication logic before you have something real to look at. what happens immediately after generation shapes the specifics of what you'll see in the first few minutes, but the mechanic underneath doesn't change: you describe the app, Mayson builds a working version with the infrastructure attached, and you edit from there. You don't need to know how to code before you start.

What "getting started" actually means with Mayson

I want to be precise about this because I got it wrong myself the first time. "Getting started" doesn't mean opening a blank canvas and dragging elements onto it, the way it does with a lot of no-code tools. It means having a conversation. You describe what the app does, who uses it, and roughly what happens when someone interacts with it, and Mayson generates a working version, not a mockup.

The practical first step is the free tier: 10 credits, no credit card required. That's enough to describe your idea, see it built, and get a sense of whether the process suits how you think before you commit anything. I'd have used this stage differently if it had existed when I started, because my first attempts at building anything were all mockups. A Fiverr developer once delivered me a beautiful Figma file for ₹12,000 and then vanished. It looked exactly like an app. It did nothing an app does.

Writing your first prompt so Mayson understands what you want

This is the part people underestimate, and it's the part that determines whether your first ten minutes feel like magic or feel like nothing happened. A vague prompt gets you a vague app. "Build me a task manager" gets you a generic task manager. "Build me a task manager where freelance designers can log hours against specific client projects and generate a weekly invoice from those hours" gets you something closer to what you actually meant.

I learned this the hard way, and not just with Mayson. That ₹12,000 Fiverr brief I mentioned was three sentences long. I assumed the developer would fill in the gaps the way I would have. He didn't, because he couldn't read my mind, and neither can Mayson. The difference is that Mayson is free to iterate on, so a vague first prompt costs you a few minutes, not a few thousand rupees and two weeks of silence.

My own first build was a small internal tool for tracking which of my client deliverables were overdue. My first prompt described the fields I wanted and stopped there. What I got was functional but generic: a form and a list, nothing that reflected how I actually work through a week of consulting deadlines. I went back and added detail about the actual workflow, client names as a dropdown, a status field with the specific stages I use, a view sorted by due date. That second prompt is the one that produced something I kept using.

What Mayson generates, and what to check first

What comes back isn't a prototype you'll need to rebuild later. It includes a working database, an authentication flow if your app needs users to log in, API endpoints connecting the frontend to that backend, and a deployed URL you can open and click through immediately. You can see what a first Mayson app looks like on the showcase page if you want a sense of the range, from consumer apps to more utilitarian internal tools.

The first thing to check isn't how it looks. It's whether the core action actually works: can you create the main object in your app (a task, a listing, a booking) and see it saved and retrieved correctly? That's the part a mockup can never show you and the part that actually matters. Cosmetic issues are easy to fix later. A broken core loop tells you the prompt needs another pass.

Making changes without knowing how to code

You make changes the same way you made the app: by describing what you want differently. "Move the submit button below the notes field," "add a status field with three options," "the dashboard should show only tasks assigned to the logged-in user." You're not editing code. You're refining a description, and Mayson regenerates the relevant part.

This is where the "good enough" instinct matters more than perfectionism does. My working theory, after watching a lot of non-technical founders (myself included) get stuck, is that perfectionism kills more first projects than lack of skill does. Ship the version that's 70% right, use it, and let real usage tell you what the missing 30% actually is. Guessing at every edge case before anyone has touched the app is time spent on problems that might not exist.

What to do when something doesn't work the way you expected

Something will not work the way you expected. That's not a Mayson-specific problem, it's true of every piece of software built by anyone, ever. The honest limitation worth naming here: a feature that involves a genuinely unusual workflow, something outside the common patterns Mayson has seen a lot of, sometimes needs a more specific, more technical prompt than the first version you tried, and occasionally still needs manual tweaking to get exactly right.

When my tracking tool's status field kept defaulting to the wrong value, my first instinct was to assume something was broken. It wasn't. My prompt hadn't specified what the default should be, so Mayson had made a reasonable guess that didn't match what I wanted. I rewrote the instruction to be explicit about the default, and it worked on the next pass. Most of what feels like a bug in your first week is actually an underspecified prompt. If you want to understand why, it helps to know roughly how Mayson's backend works under the hood, since a lot of "why did it do that" questions trace back to how the database and logic layers are actually structured.

How this compares to hiring a developer or learning to code yourself

I used to map decisions like this out as a two-by-two, cost against speed, before I'd let myself commit to anything. Old consulting habit.

Hiring a developer gets you a technical partner and, if you find a good one, real judgement about architecture decisions you can't make yourself yet. It also costs real money before you've validated whether the idea deserves it, and vetting a good developer is its own skill most non-technical founders don't have yet. Learning to code yourself is the slowest path to a first working product, though it's the path that gives you the most long-term independence if you stick with it.

Mayson sits in between: you get a working, production-grade app fast, and you own the code, so hiring a developer later to extend it is still on the table. There's a line from one of my MBA professors in Melbourne that comes to mind more often than I'd like to admit: strategy without execution is hallucination. Spending three months deciding the "right" way to build before building anything is its own kind of avoidance, dressed up as diligence.

So what's the realistic first week look like

Day one is your first prompt and your first disappointment, because the first version is rarely exactly right, and that's normal, not a sign you've done something wrong. The middle of the week is where you actually learn how to talk to Mayson: which details matter in a prompt, which ones it infers correctly on its own, where you need to be explicit.

By the end of the week, you'll know whether the idea deserves more of your time. I keep a Notion database of ideas I've decided not to build, 47 entries and counting, and most of them died in exactly this window: not because the tool couldn't build them, but because building the working version made the actual problem visible in a way the spreadsheet version never did. That's not a failure. That's the point of building something real in week one instead of spending three months deciding whether to.

Frequently asked questions

Abhishek splits his week between strategy consulting and running a small SaaS product he built without hiring a developer. He writes about building software as a non-technical founder, honestly, including the parts that didn't work the first time.