1 of 2

When creating time estimates for features, is there a standard percentage to tack on for potential refactoring?

Note: I get that refactoring is something you do along the way, you don't treat it as it's own "thing", or it's own specific task. I am talking about refactoring along the way, however I am not sure how much time I might end up spending refactoring or rewriting instead of solely implementing new features.

I've been asked to provide time estimates for each part of a web application I'm building. I'm not too experienced with expected time scales as many of the technologies I'm being asked to utilize, I have never used before. I am providing time estimates as close as I can, however, I know that along the way I will end up refactoring and even rewriting chunks of the application as I become more familiar with the frameworks.

The estimates I can come up with are based on how long I believe it will take to make the feature "work". I do not know how much time I will need to spend to make it work nicely with other parts of the application, as none of them are written yet.

Extra time spent on refactoring and rewriting as I go is an unknown for me. Is there a typical percentage of time that can be tacked onto feature time estimates that can account for potential refactoring and rewriting?

Edit: A note, my project manager is not familiar with software development. I am for all intents and purposes alone on this, with some small oversight once the project is done through a couple code reviews with a couple other individuals elsewhere in the company.