From Personal Portfolio to Software Company Website: The Architecture Behind IKECOZ

The original challenge

IKECOZ needed a public website that could represent a software company — not only a personal portfolio. The earlier archived portfolio was useful for showing individual work, but it was not structured for company services, product status, case studies, technologies, legal pages, or a production enquiry flow.

The goal became clearer over successive phases: build one official website that explains what IKECOZ builds, how work is approached, what evidence exists today, and how to start a conversation.

Why a personal portfolio was not enough

A portfolio can showcase selected projects. A software-company website also needs:

• clear service offerings
• honest product status labels
• case studies that separate verified work from future plans
• company story and founder context without turning every page into a résumé
• contact capture that does not invent success states
• privacy and terms aligned with actual behaviour

Those requirements change information architecture, content ownership, and quality rules.

Defining the company-first information architecture

The public routes were organized around company surfaces:

• Services and service detail pages
• Products and product detail pages
• Case Studies
• Technologies
• About and Founder
• Contact
• Privacy and Terms
• Blog

Navigation and footer links point to these routes as first-class company pages. The design system and shared layout keep the experience consistent while each area keeps its own typed content source.

Creating reusable typed content

Instead of hard-coding marketing copy into every page component, IKECOZ moved important content into typed modules under content/. Services, products, case studies, technologies, company, contact, and legal copy each have structured sources.

That approach makes it easier to:

• reuse the same product names and statuses across pages
• keep SEO descriptions consistent with page content
• avoid inventing duplicate company descriptions
• validate important fields before pages ship

Separating products from experiments

Not every project is a finished commercial product. The Products system uses explicit status language such as active development, prototype, and showcase. Case Studies currently focus on internal products rather than unnamed client work.

This separation matters. Visitors can understand what is shipping, what is experimental, and what is an engineering showcase without being oversold.

Building Services and Case Studies

Services describe what IKECOZ can help with — custom software, web, mobile, SaaS, AI automation, APIs, design, DevOps, games, and consulting — without claiming every engagement is enterprise-scale by default.

Case Studies document evidence from PraySync and Creatiq: problem framing, technical choices, debugging, testing, and remaining limitations. They are useful because they show process, not invented metrics.

Creating an evidence-first content standard

Across Products, Case Studies, About, Contact, and legal pages, the same rule keeps appearing: publish what can be verified, omit what cannot, and label future direction clearly.

That standard now also guides the Blog. Articles should explain real architecture and product work, not invent users, downloads, revenue, or market rankings.

Contact and legal foundations

The Contact system validates enquiry fields, applies spam and rate-limit controls, and delivers messages through a configured email provider when available. If delivery is not configured, the API does not claim success.

Privacy and Terms pages describe the website’s actual behaviour: email-based enquiry delivery, optional providers, no non-essential advertising cookies in the current public site, and no application database for contact submissions.

Accessibility and performance decisions

The marketing foundation prefers Server Components, static generation where practical, restrained motion, semantic landmarks, breadcrumbs, and readable long-form layouts. Legal and Blog pages keep prose width comfortable and avoid decorative noise that competes with reading.

Quality gates — typecheck, lint, tests where present, and production build — are part of the delivery habit rather than an afterthought.

Lessons learned

1. Company websites need content architecture, not only visual redesign.
2. Typed content reduces contradictions between pages.
3. Product status honesty builds more trust than inflated launch language.
4. Contact and legal pages must match real processing behaviour.
5. Evidence-first publishing is slower at first and clearer later.

What comes next

The Blog now extends the same evidence standard into long-form writing. Future articles can deepen product lessons, architecture guidance, and engineering process notes as more verified work becomes available.

Related reading on the site includes Services, Technologies, and About IKECOZ.