Careers
Build the shortest path from an idea to a real website.
Instantsite turns a description of a business into a complete, editable, publishable website. Most of the businesses that need one have no designer, no developer and no time, which makes the quality of what comes out of the generator the whole job.
Why Instantsite exists
A good website should not be a project.
A roofer in Austin, a med spa, a two-person consultancy: each needs a website that explains what they do and gives a visitor one clear thing to do next. The existing options ask them to choose a template before anything is known about the business, then hand over an empty page and a blinking cursor.
Instantsite starts from the opposite end. You describe the business in your own words, and the product works out the pages, the structure, the wording and the visual direction from that. The website that comes back is finished enough to publish and open enough to change.
Getting that right is a genuinely hard problem. It touches language models, information architecture, typography, page performance, billing, domains and the parts of running a small business that software usually ignores.
How we work
Principles we can point at.
Not aspirations. Each of these is visible in the product and in the code, and the line under each one says where.
Ship practical quality
A feature is not finished because it works. It is finished when somebody who has never built a website can use it, get it wrong, recover, and end up with something they are willing to put their business name on.
The generator produces a complete website rather than a starting point, and every part of it stays editable afterwards.
Speed without carelessness
We move quickly on what can be changed again next week, and slowly on what cannot: billing, publishing, domains, and anything touching a website that is already live for a real business.
Plan changes are prorated by the payment provider, a downgrade never deletes a website, and publishing writes a snapshot rather than editing what is already public.
One source of truth, or none
A price, a plan limit or a feature gate is written in exactly one module, and every screen derives from it. Copies drift, and a product that disagrees with itself about what it costs has lost the argument before it starts.
Prices come from one pricing catalogue, plan capabilities from one registry, website allowances from one policy module. The pages that display them import those, never a second copy.
Claims are tested like code
If a page says the product does something, a test reads the code that would have to do it. Marketing copy that quietly outgrows the product is a bug, and we treat it as one.
The pricing, features and resource pages derive their numbers from the modules that enforce them, and their test suites fail when a claim and the implementation disagree.
Learn from real usage
Decisions come from what people actually do with the generator (where they stop, what they rewrite, which descriptions produce a website they publish) rather than from what we imagined they would do.
Every generation records its stages, failures and costs, so a change to the pipeline can be judged on what it did to real runs.
Simplicity is earned
One text box on the home page is the simplest thing a person can be asked for. Everything behind it (reading the intent, planning the pages, choosing a direction, writing the content, checking the result) exists so that box can stay one box.
The description-first flow replaced a sequence in which you had to pick a theme before the product knew anything about your business.
Open roles
Nothing open at the moment.
We do not have an open role right now.
We are still interested in meeting exceptional people who care about AI, design and software for small businesses. If that is you, do not wait for a posting; the roles that get created usually get created around someone.
Send an introductionGeneral applications
Introduce yourself.
Applications have their own form. It goes straight to the careers inbox rather than the queue that answers sales and support, so your message is read as an application by someone who works on the product.
What to include
- What you have built, and which part of it you are proud of.
- A link to your work: repository, portfolio, a website you made, a piece of writing.
- What you would want to work on here, and why this problem in particular.
- Where you are, and how you like to work.
Send links rather than attachments. We do not accept file uploads through this site, so a message with a document attached to it may not reach us.
Open the application formApplying here
We consider every application on the merits of the work and the thinking behind it. We do not screen on where you studied, which companies are on your CV, or how closely your background matches somebody already here.
If you need something adjusted to take part (a different format, more time, a written conversation instead of a call) say so in your message and we will work it out with you. It has no bearing on how the application is judged.
Anything you send is handled as described in our Privacy Policy. Applications sent through the application form are delivered to us by email and are not stored in a database.