Approach
Each step below produces something you can read or click. If a step would not change a decision on your project, we skip it and say so.
Listen
Send a URL, a problem, or the RFP. We read it before asking for a call. The facts we need first are who has to use the site, what they are trying to finish, who on your staff will edit it, and how much time anyone has for it after launch. A 30-minute call is available when talking is faster than writing. It is not required to start.
Learn the users and the calendar
We write down the jobs people come to the site to finish: renew a membership, register for the briefing, find the grant deadline, see this week's shifts. A list of software features is not a job.
We also ask for your year. When do renewals go out? When does conference registration open and close? When is the application deadline, the start of term, the board meeting that approves the budget? Those dates decide what the home page shows in which month, and they decide when a launch is safe. A launch in renewal week is not.
If we can talk to two or three of the people who use the site, a member, a parent, a volunteer, we do. If we cannot, we work from what your staff hear on the phone and say that is what we used.
Write the scope
You get a written scope before project work starts: what is in, what is out, what we need from you, and when. A change after that is another written note with its own price and date. There is no rate card. The number is for that scope.
Design and show the hardest screen
Before building the whole site, we build the screen most likely to go wrong, usually the renewal, the registration, or the page that has to work in a hallway on a phone. You click it on your own phone and tell us what is wrong with it. The working concepts are public examples of this step.
On a bid, a slice like this uses your organization's name only with a visible line saying it is a working draft by LSCalado and not your official site, and it is hidden from search engines.
Build and test
Engineering, content entry, and a pass on a phone for every template. Before launch we check the forms, keyboard use, color contrast, page titles, and redirects from the old addresses, and we restore the backup once to prove it works. The accessibility target is WCAG 2.2 AA, described on the accessibility page.
AI tools may help with parts of this: drafting test cases, searching logs, or sorting a content inventory. A person reviews the result before it is used, and the person who signs off on the work is Leonardo.
Launch, document, and support
We launch in a week you choose, away from your busiest dates. You own the code we write for you, the content, and the accounts from delivery. Your editors get short notes in plain language: how to edit a page, add an event, change a deadline, and who to call. The notes also say where the domain is registered and how a backup is restored.
Improve
After the first busy season on the new site, we look at what happened: which forms people abandoned, which pages staff still get calls about, what editors avoided. Small fixes go into care. Anything larger becomes a new written scope. You can also leave with the keys. Care is described on the engagement page.