Where do i start?
First, you give up the idea that you need to -- or should -- make a "game engine." It's a waste of your time. You don't need an engine to make a game, and given your documented level of experience you aren't capable of making one that measures up to your own standards yet anyway, because you know almost nothing about what goes into game development or game engines.
You need to learn that. Which means you just need to worry about making your game.
What design do i need to do in paper? Diagrams and such.
You don't need to do anything on paper, although you can if it helps you refine your ideas.
What does a game engine need to work? What are the main classes i will need?
That depends on what kind of game engine it is, and what its goals are. It's also not something you need to think about right now.
After I have built the basics to run the game how do I improve from there?
As you're building something, you'll come across problems you have to solve in ways that you're not super thrilled out, that you think could be solved better but which you're currently prevented from solving better by some other issue or architectural decision you've already made. Some of these you'll solve immediately. Others you'll put off. When you're "done," you can maybe consider going back to revisit the issues you've put off.
The "basics" of C++ is probably not enough to jump immediately into creating your own 2D game with OpenGL. Generally I'd recommend starting with text-mode, console-based games first, to flesh out your ability with the language and to practice some common game development idioms and techniques. Can you write a text-mode guess-the-number game? What about blackjack? Or hangman? What about a text adventure game like Zork?
If you feel comfortable tackling tasks like that you should try moving on to windowing and graphics using GLFW or the like, perhaps recreating Pong or Tetris.
As you do this you'll have multiple projects under your belt, wherein you learned (hopefully) at least one new skill. As you complete each project you can look back at your code at the things you feel you'd reuse for your next project and you carry that code forward. Eventually, do this enough times, and that's your own basis for your own game engine.
You also should disabuse yourself of the goal to "do everything yourself" sooner rather than later. Within practical limits you are always going to be using libraries and software that other people have written for you, and you can still understand how those libraries work without having to build them yourself anyway. In fact, you're rather likely to create a disaster if you just trying to build everything yourself from scratch, because you're assuming you're going to be able invent all the same technologies that we as a collective industry have spent years building and refining. And the chance of that is rather small.
Instead, try to look at the decision like this: if you're talking about a component of your project that is unique and critical to the business success of your project, that's usually a good case for building a thing yourself. Things like gameplay mechanisms you'd like to show off, or maybe an incredibly novel method of non-photorealistic rendering, or whatnot. Things that do not constitute unique selling factors of your project you should consider "buying" (using existing implementations of, even if free). This frees up your time to focus on the unique aspects of your project that will make it shine, and decreases the risk that, for example, your crash reporting or analytics code will fail spectacularly because you made a rookie mistake instead of using a battle-tested off-the-shelf solution.
The exception would be, perhaps, things you want to be able to do unique and interesting work in but can't yet. For example, if your goal is to be an amazing graphics programmer who builds all kinds of awesome new rendering techniques or whatever, then pretty soon after you learn how the basic graphics pipeline works (by using an existing rendering API), you'll want to start tinkering on your own to develop your skills and knowledge. But if you're not interesting in pushing graphical boundaries, there's not as compelling a reason to be writing your own low-level D3D12 code to move a few hundred sprites around (for example).
