Nobody told me to build this. It wasn't for a class, it wasn't to pad a resume, and it wasn't because I thought it would look good in an interview. I built it because I got to college as a finance major and within the first few weeks realized something nobody warns you about: there's a massive gap between what high school economics teaches you and what college expects you to already know. You can define GDP, you can explain what CPI measures, but when an upperclassman at a club meeting starts talking about what the latest jobs report means for Fed policy, you realize you can't actually read the economy. You just memorized definitions. I talked to my classmates and it wasn't just me. Almost everyone was dealing with the same thing. The information exists, it's scattered across YouTube, news sites, FRED data, and market reports, but there's no single place that pulls it all together and explains it in a way that actually builds understanding. So I built one.

    Macroscope is a free dashboard that tracks 51 economic indicators, scores them 0-100, and explains everything in plain English. Built the whole thing using AI as a pair programmer. 9,434 lines of TypeScript later, it's live and I'm trying to figure out what comes next.

    Some honest numbers:

    • Running costs started at $54/month ramping up to $134/month (hosting + database + API). Migrated my entire infrastructure to cut it down to $13/month. That migration alone taught me more about building a real product than anything else in this process.
    • Revenue: $0
    • Users: still early. Getting initial feedback now across a few communities.
    • Total investment: about 6 months of my time and roughly $400 in infrastructure costs

    Here's what I've actually learned that might be useful to someone else at this stage:

    Talk about the problem, not the product. Every time I described what I built, nobody cared. Every time I described the gap between high school and college economics, people clicked. The problem is the hook, the product is just the answer.

    Ship before you're ready. I kept polishing and adding features instead of showing it to anyone. The feedback I got in the first 48 hours of sharing it publicly was worth more than a month of building alone. One Reddit comment pointed out that my landing page was confusing, and he was completely right. I never would have caught that on my own.

    Your costs will surprise you. I budgeted for hosting but didn't think about database read quotas, API token costs, or the fact that automated jobs running 4x daily eat through limits fast. Had to completely migrate my infrastructure once already. If you're building something, map out every cost from day one, not just the obvious ones.

    New account restrictions are brutal. Every platform I tried to share on blocked me because my accounts were new. Reddit, Hacker News, all of them have karma or age gates. Budget at least a week of genuine participation before you can actually post your project anywhere.

    Now I'm at the monetization question. The plan is freemium. Keep the free version fully functional, add a premium tier at $5-8/month with extended features. At $8/month I need 17 paying users to break even. At $5/month I need 27. The target audience is college finance students, so the price has to be impulse-buy territory.

    The question I keep going back to: is it too early to even think about monetization when I barely have users? Or is this exactly the right time to build the infrastructure for it so it's ready when demand shows up?

    Would genuinely appreciate thoughts from anyone who's navigated the free-to-freemium transition. Still very early in this.

    I've spent $400 and 6 months building something that makes $0. Here's why I'm not stopping.
    byu/CarlsonDG inEntrepreneur



    Posted by CarlsonDG

    3 Comments

    1. mandevillelove on

      you’re doing it right, keep validating the problem with real users first bcoz monetization gets a lot easier once ppl actually rely on what you’ve built.

    2. You’re confused about monetization because you didn’t talk to customers in the beginning about their problems. So you are correct. It’s too early.

      Since your burn is low and you’re not past the point of return you should go back and talk to potential users about their problem. Find out what they do pay for and why they would change or not. Then you’ll understand monetization.

      Always approach monetization from the standpoint of the customers behaviors and problems. Don’t think about it as a stage of the product like you’re doing here. You’ll save yourself a lot of grief. Trust me. I’ve lost a lot of money on doing this the wrong way.

    3. You may have identified a problem successfully, but with a very small addressable market. College finance students don’t have a lot of money, there aren’t that many of them, and even if both of those things weren’t true, you haven’t necessarily found a pain point that people a feel strongly enough to pay for, especially when they’re already paying 1000x your cost for a college education to achieve the same result.

      Also, for context, the upperclassman who can interpret economic data like that is doing financial astrology. The application of the principles you’re describing is 97% academic and loaded with unverifiable assumptions; real financial work uses far different measures.

    Leave A Reply
    Share via
    Share via