Project Background
The first version of this site is meant to solve a clear delivery problem: when someone opens the site, they should quickly understand my job direction, core engineering capabilities, representative projects, and ways to contact me. It is not meant to be a complex product platform.
The site also acts as a long-term writing container. A resume gives a quick overview, but project pages and blog posts are better for explaining debugging paths, tradeoffs, and engineering results. The roadmap therefore treats content structure as the first deliverable.
Core Problem
The core problem is scope control. A personal portfolio can easily become crowded if it tries to include every possible feature. Login, database storage, comments, dashboards, animations, and complex CMS workflows are not required for the first delivery loop.
Another issue is content priority. If the site looks polished but the projects are still written as tool lists, it will not communicate engineering ability. The first version has to make the main line clear: embedded software, embedded Linux, AI Agent tools, problem diagnosis, solution verification, and project delivery.
My Approach
The first version keeps the structure simple: homepage, online resume, project portfolio, blog list, blog detail pages, about page, and 404 page. The homepage explains direction and highlights representative work. The resume page stays concise and result-oriented. The project page uses consistent fields for positioning, role, challenge, solution, and result.
For content maintenance, Markdown is used for blog posts. This makes it easy to add technical reviews without changing the whole site. Project data is centralized so the homepage, project page, and resume can reuse the same facts without drifting.
Debugging and Verification
The first verification path is local static checks. The checks look for broken content assumptions, missing project fields, missing blog sections, and risky public information. This helps catch problems before the site is published.
The second verification path is the Astro build. A successful build proves that routes, content collections, Markdown rendering, and static output all work together. After building, the generated pages can be inspected for homepage, resume, projects, blog, about, and article details.
Final Result
The first-version goal is a site that can be opened, read, and updated without a custom server. Visitors should be able to understand the direction within seconds, then continue into project details or technical reviews if they want deeper context.
The project page becomes the main evidence area, while the blog becomes the place for engineering review. The PDF resume remains private until a properly redacted version is ready, so public pages do not expose unnecessary personal information.
Review Takeaways
A resume portfolio should not start by adding every feature. It should start by making the evidence chain readable: what problem was solved, what work was done, what result was achieved, and what can be reviewed later.
The roadmap is therefore intentionally conservative. First make the site clear and safe. Then add richer articles, project diagrams, screenshots, or more interaction only when those additions improve understanding rather than adding noise.