Your question in rather opinion based - there are no strict guidelines weather you should start with design first or functionality of main features as separated components that could later be attached to your interface.
It is up to your judgement, skill and budget to consider learning UI design or hiring a professional designer.
I'd say - if you're interested in design, have designer skills or you're sure that you can achieve same quality as a pro in reasonable time - go for it!
About the part of what goes first - I'm not going to stress the way I prefer, it's all opinion based. But you've said you work in a company for a year now - you should know the workflow by now. Why not use same approach as the company uses - it is familiar to you so there's less chance of having mistakes you never heard about.
But let's say you're unhappy with the workflow you know by now, you want to know other ways or simply need unsure what effect your actions might have.
Let's look at a few ways an app can be created.
For the sake of an example let's say the app is a step counter with statistics. Abstract examples are harder to understand anyway.
1) Build a screen list. My favourite way. Easy to understand even for a non-developer. Make a sheet with all the screens and lines to show screen relations.
Then, when you're satisfied with workflow you can list all the features with better understanding how to implement them in the current system. It also helps to keep the code separated and clean in your head as every feature will know it's place regarding it's screen.
2) Code first. Not the official name of the approach btw :) A well working alternative - just write all the model (model as in MVC), so it's easy to know what you're working with. Then, make the controller, so you can change the state of the model. It's fun that only a true programmer will appreciate. Not much you can show to other team-members/client meanwhile, but you can see the output in the console and know it's working! Then attach the visuals, sound feedback that other parts of the View. It doesn't really matter how your View will be like - it is the engine that's important.
In both cases, if done correctly, changing a part of your app won't affect the other. Both apps can be written with any standard, guideline, framework. It's merely a way to organise it in a way more understandable to you.
There are unlimited ways to break up the app into smaller tasks to help you understand your ToDo list. I won't be able to cover them all here.
There is no rule, only guidelines, so when you're making an app, think what you want to see or do first. Have your own guideline for consistency, but try approaching every program based on what's the best solution rather sticking to only one way.