Craftly for Laravel
What belongs in the description of a Laravel application, what the generated project is, and how a developer carries it forward.
1 Overview
A Laravel application is more than a set of pages. It stores records, tells users apart and applies rules. That makes the description you give Craftly more important here than for a website theme: a multi-agent system writes the PHP code from what you say in the conversation, and whatever you leave out has to be guessed or left out.
What to describe
Write the description down before you start the conversation. Plain language is enough, but five things should be in it. The examples below use an invented room booking tool as an illustration.
- The things the application manages: rooms, bookings, customers. For each one, the fields it has and which of them are mandatory.
- The people who use it. List the roles and what each role may see, create, change and delete.
- The processes, step by step: what happens when a booking is requested, confirmed or cancelled, and who is notified at each step.
- The rules. A room cannot be booked twice for the same time. A customer sees only their own bookings. Write rules as sentences that are either true or false.
- The exceptions: a wrong entry, a missing permission, an empty list, a record that someone else has just deleted.
If a Figma design of the screens exists, Craftly can start from it. A design shows what a screen looks like. It does not say which rules apply behind it, so the written description is still needed.
A simple test: give the text to a colleague who does not know the project. Every question they ask marks a gap.
What you get
The result is a Laravel application as ordinary PHP code, not a configuration stored inside a builder. The owner can keep it and edit it. In practice that means the project can go into version control, and a developer who knows Laravel can read and change it with the usual tools.
What a generated project contains in detail and how it is handed over is described on the Craftly product site. Check that before you set a schedule.
The first review
Test the application against your description before anyone builds on it.
- Walk through every process once per role, including a role that should be refused.
- Try to break each rule on purpose: book the same room twice, open another customer's record.
- Fill forms with nonsense, leave mandatory fields empty, submit twice.
- Ask a developer to look at how the data is structured. This is the part that is most expensive to change once real records exist.
Note every deviation with the screen, the role and what you expected. That list is either the input for a more precise description or the task list for a developer.
Continuing development
From here the project behaves like any other Laravel project, and it needs the same care.
- Put the code into version control on the first day, so every later change can be traced and undone.
- Keep a test environment separate from the live one. Changes go to test first.
- Before real data goes in, have a developer review everything around login, permissions, personal data and payments.
- Plan connections to systems you already use, such as accounting, email delivery or a payment provider, as separate developer work.
- Agree who applies updates. Laravel and the packages it depends on receive new versions regularly, and someone has to install and test them.
- Have data protection and contract questions checked by a lawyer.
If you want to keep generating and also edit by hand, find out on the product site how the two fit together before you mix them.
When it fits
Generation works best where the rules can be stated: internal tools, customer portals, a first version of a product that people need to click through. If the rules are still being argued about, settle them first. A generator cannot make that decision, and neither can a developer.
2 Who this is for
Founder
You get a checklist for describing your product idea as records, roles, processes and rules, and a realistic picture of the review and maintenance work that follows once the Laravel code exists.
Operations lead
You see how to put an internal process, with its roles, steps and exceptions, into words precise enough to generate a tool from, and how to test the result against the way your team actually works.
CTO or tech lead
You learn what arrives on your desk: ordinary Laravel code that goes into version control, needs a security and data structure review, and is then maintained and updated like any other project.
3 Questions and answers
How detailed does my description of the Laravel application have to be?
Detailed enough that a colleague who does not know the project has no questions left. Name the records and their fields, the roles and their permissions, each process step by step, the rules, and what happens when something goes wrong. Technical terms are not needed. Missing rules are the usual reason a generated application behaves differently from what was expected.
Can my own developers keep working on a generated Laravel application?
Yes. The project is ordinary PHP code that the owner can keep and edit, so a developer who knows Laravel works on it with the usual tools. Put it into version control straight away and let the developer review data structure, login and permissions before real data is entered.
Does Craftly connect the application to our existing systems?
This page makes no claim about connections to particular third-party systems, so do not plan on them. Treat links to accounting, payment or email systems as separate developer work on the generated code, and check the Craftly product site for the current scope.
5 From the blog
Try it with Craftly
Craftly generates WordPress themes and Laravel applications from a description or a design.