You really shouldn't roll your own.
It's not like normal programming, where you can reinvent your own wheel with a different shape or color.
Any small detail can introduce a weakness you don't even know about, and which can completely break your scheme.
As your skill in designing crypto is (understandably) low, the likelihood is high. The more sensitive are the data you entrust to your scheme, or the longer you use it, the higher is the impact.
High likelihood + high impact -> high risk.
Not even professional cryptographers invent schemes and use them straight away.
Plus, even good algorithms can be implemented badly. Again, implementing algorithms (even good algorithms) is something you shouldn't do, unless it's really necessary. If anything, inventing your own algorithms is even (by far) less necessary.
Do not put this stuff in production, period.
Do not use this stuff for any information you care about, period.
That said, if you want to design something for learning purposes only, @PeterHarmann's advice is valid.
I'm just going to expand a bit on symmetric algorithms.
Most block ciphers are based on either of two approaches, SPN or Feistel networks. Choose one.
If you go with SPN, the round number can be relatively low, but remember you need a quite large P-box.
You also need to design a way to obtain the round key.
Now comes the fun part... break it!
I don't design crypto, but if I had to, for whatever unlikely reason, I would check that the scheme is reasonably secure at the very least against linear and differential cryptanalysis.
It's not a piece of cake, but you're doing it for learning purposes, right?