From Idea to Deployment: Building TalesOfCoding with .NET 8

From Idea to Deployment: Building TalesOfCoding with .NET 8

@danaer 16 Mar 2026 • 7 min read


Welcome to Tales of Coding First Blog Post below you can learn all about how an idea turned into a real app deployed on Azure! Building a Real ASP.NET Core App is very cool but building a project from scratch always sounds simpler at the beginning than it turns out to be, possibly hell in practice. TalesOfCoding started as an idea for a clean, creative platform focused on coding content, tutorials, and blog posts, but the real value of the project came from the process of actually building it: shaping the UI, making technical decisions, solving unexpected issues, and pushing it toward a real deployment.

This was not just an exercise in writing code. It became a full product-building experience that touched design, architecture, debugging, usability, deployment, and continuous refinement.

What TalesOfCoding is

TalesOfCoding is a web application built with .NET 8 / ASP.NET Core MVC. The goal was to create a platform that feels personal and polished while still being functional and scalable enough to grow over time.

The project includes features such as:

  1. blog and tutorial content
  2. creator-oriented pages and dashboards
  3. authentication and account management
  4. category-based browsing
  5. custom styling, including dark mode support
  6. production deployment on Azure
  7. domain configuration and live publishing

Even though the application is still evolving, it already reflects many of the same challenges that appear in real professional software work.

Why this project mattered

What made this project valuable was not only the final result, but the range of engineering work involved in getting there.

It required me to move constantly between different layers of development:

  1. front-end presentation and user experience
  2. server-side MVC structure
  3. data-driven rendering
  4. authentication flow
  5. styling consistency across pages and themes
  6. deployment and production environment issues

That mix made the project a useful test of both technical skill and practical problem-solving.

The full tech stack

TalesOfCoding was built primarily with:

  1. .NET 8
  2. ASP.NET Core MVC
  3. Razor views
  4. Entity Framework Core
  5. ASP.NET Identity
  6. SQL-based persistence
  7. Azure App Service
  8. custom CSS with light/dark mode styling

This stack gave me a strong balance between productivity, structure, and room for clean architecture decisions.

What I learned while building it

1. UI polish is real engineering work

One of the biggest lessons from this project was that visual refinement is not separate from development. Small issues like text contrast, dark mode inconsistencies, link styling, spacing, hover states, icon balance, or component alignment may look minor individually, but together they shape whether an application feels finished or rough.

A large amount of time went into details such as:

  1. improving text readability in dark mode
  2. keeping visual consistency across buttons, badges, cards, and links
  3. refining navigation states and hover behavior
  4. making creator dashboard elements feel coherent
  5. cleaning up footer and layout presentation

This reinforced an important point: good UI work is not just decoration. It is part of product quality.

2. Reusable styling matters more than quick fixes

Throughout the project, I repeatedly ran into cases where a small visual issue could be “patched” quickly with a one-off CSS rule. Instead of piling up hardcoded overrides, the better approach was to think in terms of reusable classes and predictable styling patterns.

That pushed the project toward better habits such as:

  1. introducing custom classes instead of styling random elements directly
  2. keeping visual rules scoped and readable
  3. avoiding unnecessary duplication
  4. making changes in a way that would still make sense later

This is one of the clearest areas where the project helped strengthen maintainability-focused thinking.

3. Debugging is often pattern recognition

Not every problem came from complex logic. Many issues were caused by the interaction between layout, styling inheritance, Razor markup, Bootstrap defaults, or dark mode overrides.

Fixing those problems required a consistent process:

  1. identify the exact symptom
  2. inspect where the behavior is really coming from
  3. isolate whether it is markup, CSS specificity, framework defaults, or logic
  4. test a focused fix
  5. verify that the fix does not break other pages or themes

That process became especially useful when dealing with UI inconsistencies that seemed simple at first but had multiple causes.

4. Building for production changes your mindset

Getting an app running locally is one thing. Deploying it publicly is another. Once deployment entered the picture, the project stopped being just a coding exercise and became a product delivery exercise.

That included work around:

  1. Azure deployment flow
  2. app startup behavior
  3. domain connection
  4. production readiness checks
  5. privacy and terms pages
  6. confidence about what is safe to ship now versus what is only polish work

This part of the project taught an important practical distinction: not every issue is equally important. Some things are release blockers, and some things are simply refinement tasks. Learning to tell the difference is part of shipping software responsibly.

Challenges I ran into

A project like this naturally produced friction. Some of the recurring challenges included:

Styling conflicts

Dark mode and component-level styling created repeated issues with visibility, contrast, hover behavior, and inherited styles.

Consistency across pages

As more views were added, maintaining a shared design language across dashboards, blog pages, auth links, category pages, and layout sections became more important.

Balancing speed and clean code

It was tempting at times to fix something as fast as possible. The better long-term choice was usually to pause, simplify the structure, and apply a cleaner solution.

Deployment uncertainty

Publishing to Azure introduced the usual production questions: what is cosmetic, what is structural, what is urgent, and what can safely wait for a later polish pass.

How I approached fixes

One of the most useful parts of this project was developing a clearer troubleshooting approach.

Instead of treating every issue as a random problem, I started treating them more like a repeatable workflow:

Analyze

Understand the exact problem instead of guessing.

For UI issues, browser inspection tools were often the fastest path to the real cause.

Isolate

Reduce the issue to the specific view, selector, component, or behavior involved.

Test

Try the smallest clean fix first, rather than stacking multiple changes at once.

Verify

Check whether the fix works in context, including across dark mode, hover states, layout changes, or related pages.

Refine

If the solution works but feels sloppy, improve it before moving on.

That cycle made the project much more manageable and is directly transferable to professional software work.

Professional skills this project strengthened

This project helped develop and demonstrate skills in several areas:

Application development

  1. building an ASP.NET Core MVC application end to end
  2. structuring views, controllers, and models clearly
  3. working with Identity and authenticated UI flows
  4. thinking about maintainability rather than just functionality

Front-end implementation

  1. translating visual ideas into consistent UI
  2. resolving CSS conflicts and theme-specific issues
  3. improving usability and visual hierarchy
  4. refining components through iteration

Debugging and quality control

  1. tracing root causes instead of guessing
  2. testing targeted fixes
  3. distinguishing between functional defects and cosmetic issues
  4. improving confidence in release decisions

Deployment and delivery

  1. deploying to Azure
  2. handling domain/live environment concerns
  3. moving from local development to a publicly available app
  4. evaluating readiness in a practical way

Product thinking

  1. deciding what deserves immediate attention
  2. prioritizing user-facing quality
  3. understanding that shipping is not just coding, but also judgment

What I would improve next

Like any real project, TalesOfCoding still has room to grow. Some of the next areas I would like to focus on are:

  1. stronger automated testing coverage
  2. more component standardization across pages
  3. additional performance and accessibility review
  4. continued refinement of the creator experience
  5. future platform features as the project expands

That is one of the reasons projects like this are valuable: they do not just end when the first version goes live. They keep teaching you as they evolve.

Final thoughts

TalesOfCoding taught me far more than syntax or framework usage. It taught me how much real software development depends on iteration, judgment, debugging discipline, and attention to detail.

Designing, building, and deploying this app made one thing very clear: a good project is not just a collection of features. It is the result of many decisions made carefully across code quality, user experience, troubleshooting, and delivery.

That is what made TaleOfCoding worthwhile. It was not only about creating a website. It was about learning how to shape something into a real product.