Founders Round Economics — Landing Page Planning
This page is being used to help plan the landing page for the
Founders Round Economics project.
If you are Robert, please use the instructions below with ChatGPT.
The goal is to produce a complete, self-contained implementation brief
that can be sent to the web developer who will build the page.
Important:
The web developer has not been part of our previous
conversations. Do not assume that the developer has access to anything
you have discussed with ChatGPT previously.
Your final response therefore needs to contain all of the relevant
information necessary for the developer to understand what we are
trying to accomplish.
Accuracy is extremely important. Do not invent facts,
statistics, claims, quotations, financial information, company
information, or other details. If information is missing or uncertain,
clearly identify it as something that needs to be confirmed rather
than guessing.
Your Task
Help me develop the landing page for:
https://millennium-asset.biz/founders-round-economics/
First, determine what this landing page is intended to accomplish based
on the information available to you and anything I provide during our
conversation.
Then develop a complete recommendation for the page.
Do not limit your response to suggested marketing copy.
I need a practical specification that a web developer can use to build
the page.
1. Project Purpose
Explain:
- What the Founders Round Economics project is
- Why this landing page is being created
- What the page should accomplish
- Who the intended audience is
- What action we ultimately want visitors to take
If any of these are unknown, explicitly identify the missing information.
2. Recommended Page Structure
Recommend the complete structure of the page from top to bottom.
For each section, explain:
- The purpose of the section
- What information it should contain
- The recommended headline
- The recommended supporting copy
- Any call-to-action
- Any images, graphics, charts, diagrams, or other visual elements that would be useful
3. Proposed Copy
Write the actual proposed copy for the page.
This should include, where appropriate:
- Page headline
- Subheadline
- Introductory copy
- Section headings
- Body copy
- Calls to action
- Button text
- Supporting statements
- Disclaimer or qualification language if needed
Do not make unsupported claims. If a statement requires information
from Robert or Millennium Asset before it can be published, mark it
clearly as:
[CONFIRM BEFORE PUBLISHING]
4. Facts and Claims Requiring Verification
Create a separate list of every factual claim, statistic, number,
financial figure, performance claim, quotation, date, name, or other
potentially verifiable statement that should be confirmed before
publication.
For each item, explain what needs to be verified.
Do not assume that something is true merely because it would make
the landing page more persuasive.
5. Design and Layout Recommendations
Describe how the page should look and feel.
Consider:
- Overall visual style
- Page width and layout
- Typography
- Colors
- Use of images
- Use of charts or other financial visuals
- Section spacing
- Calls-to-action
- Mobile responsiveness
- Relationship to the existing Millennium Asset website
The recommendations should be practical for a web developer working
within the existing website rather than assuming that an entirely new
website will be built.
6. Technical / Implementation Requirements
Identify anything the developer will need to know to implement the page,
including:
- URL
- Forms
- Email addresses
- Links
- Downloads
- Tracking requirements
- Analytics
- Integrations
- Embeds
- Images or other assets
- Required plugins or third-party services
- SEO considerations
- Accessibility considerations
If you do not know whether something is required, say so.
7. Open Questions
Create a concise list of questions that Robert needs to answer before
the page can be finalized.
Do not hide uncertainties. If an important decision cannot be made from
the available information, identify it here.
8. Final Developer Handoff
At the end of your response, provide a section titled:
DEVELOPER HANDOFF — FOUNDERS ROUND ECONOMICS
This section should be self-contained.
Someone who has never seen this conversation should be able to read
only this section and understand:
- What the page is for
- Who it is for
- What the page should say
- What sections it should contain
- What the visitor should do
- What design direction should be used
- What assets or information are required
- What facts still need confirmation
- What decisions Robert has made
- What the developer should actually build
Do not refer to “our previous conversation,” “what I told you
earlier,” or information that is not included in the final handoff.
The Developer Handoff should be written as an
implementation brief, not as a conversation with Robert.
Decision Rules
When making recommendations:
- Prioritize factual accuracy over persuasive language.
- Clearly distinguish known information from assumptions and recommendations.
- Never invent missing information.
- Do not fabricate financial data, investment performance, customer numbers, testimonials, partnerships, credentials, or regulatory claims.
-
If the project involves financial or investment-related claims,
identify claims that may require legal or compliance review before
publication. -
If there are multiple reasonable approaches, explain the alternatives
and their tradeoffs. - Do not make a recommendation solely because it sounds more impressive.
-
Keep the final proposed page practical and appropriate for Millennium
Asset’s existing website.
Separate Known Information From Recommendations
At the end, clearly separate:
- APPROVED / KNOWN INFORMATION
- RECOMMENDED INFORMATION
- INFORMATION THAT MUST BE CONFIRMED
This distinction is important because the developer will use your
response to build the actual page.
What Robert Should Send to the Developer
After reviewing your proposed plan, Robert should make any necessary
corrections or decisions and then send the
entire “DEVELOPER HANDOFF — FOUNDERS ROUND ECONOMICS”
section to the web developer.
The developer should treat that section as the working specification
for the page, while recognizing that anything marked
[CONFIRM BEFORE PUBLISHING] still requires verification.